Subject: Re: [irs-discuss] IRS comments
From: Thomas Nadeau <[email-masked]>
To: Alia Atlas <[email-masked]>, Edward Crabbe <[email-masked]>
Cc: David Meyer <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 31 Aug 2012 18:56:58 -0400
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>

On 8/30/12 8:43 PM, "Alia Atlas" <[email-masked]> wrote:

>On the encap/decap, I certainly view encap as simply a different type
>of next-hop that a route to the RIB can have.  Similarly, one can view
>decap as treating a particular label/prefix - though that may require
>more complexity.

	As well as also recursing to look into another table. For example, l3
vrfs connected to VPLS.

>Negotiation is another area to think about too.  Clearly, there will
>be some capability negotiation needed as part of IRS - as well as the
>ability to query for what capabilities are supported by the routing
>element.

	I would rather do capability advertisement rather than negotiation. That
is, agents should be able to understand what sorts of bits, knobs and
buttons they can fiddle with, but I do not think it is important to have a
full negotiation between the IRS agent and client about the diffs.  Lets
keep things as simple as possible.

	--Tom

>Incidentally, if you are interested in writing down your thoughts
>around different architectures for where parts of the routing system
>might live and how they should/would interact with IRS, I'd encourage
>you to do so and to chat with Dave Meyer, who has agreed to take on
>looking at such pieces.
>
>While I do think that migrating the entire routing system except for
>RIB off of a routing element would be for rather specialized
>environments, I am also concerned that we consider the different
>architectural possibilities when defining IRS so that we don't end up
>going down an insufficient path.
>
>Alia
>
>On Thu, Aug 30, 2012 at 9:16 PM, Edward Crabbe <[email-masked]> wrote:
>> Yep;  not having to run an IGP on the box, which is great for those
>>people
>> not wanting / needing core internet protocols on their devices.  The
>> standard set of 'SDN' talking appoints applies here in terms of
>>development
>> speed, performance improvements resulting from use of modern commodity
>> compute, friendliness of development environment, potential for
>>decreased
>> bug count* etc etc.
>>
>> It's a specialized use case, but it exists.
>>
>> However, my fundamental point is that with IRS as defined currently (ie
>>PBR
>> with extensible match fields on on RIB recursion + additional
>>monitoring and
>> data collection hooks) you can do hypothetically do away with IGPs.
>>Indeed,
>> assuming that the encaps is applied at some other device (since IRS as
>> currently described doesn't account for encap/decap application or
>> negotiation functionality)  you can effectively replace a significant
>>number
>> of protocols (including stateful PCE) should you want to.   :P
>>
>> <can of worms>
>>
>> *The benefits in terms of decreased bug counts above is really varies
>>with
>> how complex we make IRS of course.
>>
>> On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>>>
>>> Yep, the context of our original discussion was never PCE as we
>>>understand
>>> its CSPF or some form like that. Our concern was  is there a strong
>>>use
>>>
>>> case for non-constrained SPF?
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[email-masked]]
>>> Sent: Thursday, August 30, 2012 5:34 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> Nope, not specifically, but it strongly implies that there is some
>>>form of
>>> SPF running given the use of constraints in the draft.
>>>
>>> On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal)
>>> <[email-masked]> wrote:
>>>
>>> That doesn¹t talk about centralized SPF, does it ?
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[email-masked]]
>>> Sent: Thursday, August 30, 2012 4:12 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01
>>>
>>> On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal)
>>> <[email-masked]> wrote:
>>>
>>> Œoperational model¹ = IETF draft that describes the use case.
>>>
>>> Œlarge¹ = 40K LSAs, 500 IGP nodes.
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[email-masked]]
>>> Sent: Thursday, August 30, 2012 2:44 PM
>>>
>>>
>>> To: Dutta, Pranjal K (Pranjal)
>>>
>>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
>>>
>>>
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> please define 'operational model' ( and 'large' :) .
>>>
>>> On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal)
>>> <[email-masked]> wrote:
>>>
>>> Hi,
>>>
>>>          I believe that¹s 10% of what overall work that router does
>>>today
>>> w.r.t routing. I would like to see an operational model how such
>>>centralized
>>> SPF can
>>>
>>> provide end-to-end convergence of large number of flows efficiently.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Pranjal
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: Edward Crabbe [mailto:[email-masked]]
>>> Sent: Thursday, August 30, 2012 11:59 AM
>>> To: Alia Atlas
>>> Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu;
>>> [email-masked]
>>>
>>>
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>>
>>> Alia;
>>>
>>>
>>>
>>> If there is
>>>
>>>
>>>
>>> a) a mechanism for installing routes, pbr or otherwise, which recurse
>>>to
>>> directly connected nexthops
>>>
>>> b) a mechanism for gathering topological information
>>>
>>>
>>>
>>> then you've inherently enabled centralized spf.
>>>
>>>
>>>
>>> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:
>>>
>>> I haven't seen a good description of what is intended or desired by
>>> moving the SPF functionality to a centralized location.  Clearly such
>>> centralization can have a very bad impact on convergence - which is a
>>> strong motivator for simultaneously computing fast-reroute
>>> alternatives (with guaranteed coverage ala MRT) and installing both.
>>>
>>> I don't see IRS as having a way of "turning off" the SPF computation
>>> in the IGP; a different lobotomized IGP protocol/process would be
>>> needed.
>>>
>>> Alia
>>>
>>>
>>> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
>>> <[email-masked]> wrote:
>>> > "LSDB (I saw an email which talks about reducing IGP to link
>>> >> distribution protocol and running SPF in centralized network
>>> >> controller)"
>>> >
>>> > I have seen discussions in the past on this and in fact I didn't get
>>> > precisely what is meant. If anybody in the list could brief very
>>> > precisely that would help a lot.
>>> >
>>> > Here is my understanding - the routers would do LSA/LSP flooding for
>>> > OSPF/ISIS as it is done today. So routers would build neighboring
>>> > relationship/adjacencies to participate in flooding and each router
>>>builds
>>> > its LSDB.
>>> >
>>> > Then the IRS "application" would track LSDB changes and pull up the
>>> > "diffs" from each router (thru "controller") whenever there is a
>>>change. The
>>> > application would compute SPF on behalf of each router (LSDB). The
>>>result of
>>> > the compute would be pushed by application to each Router (thru
>>>controller)
>>> > and inject entries into RIB.
>>> >
>>> > Is that correct? How different this going to be from PCE?
>>> >
>>> > If this is correct then perhaps we would like to ask what are the
>>> > scalability numbers in LSDB we are talking about?
>>> >
>>> > The "application" would be running in a high performance server and
>>>so
>>> > SPF compute there is not an issue and perhaps it is good way to
>>>synchronize
>>> > FIB update (to a certain extent) to avoid u-loops etc.
>>> >
>>> > But when we are managing all routers in the purview of the
>>>application,
>>> > the computing power in each router is not uniform. To be realistic,
>>>I have
>>> > some concerns on how much "real-timeness" we could achieve between
>>> > application and controllers on such proposals, esp. when scaling
>>>numbers are
>>> > high. This leads to higher time lag on inconsistency between
>>>application SPF
>>> > compute and FIB update. It's almost like the classic "slow peering"
>>>issues
>>> > with TCP like protocols - the high performance peer is slowed down
>>>by low
>>> > performance peer.
>>> >
>>> > Static route interface is good thing because it is a state that
>>>persists
>>> > longer.
>>> >
>>> > IGPs may be deployed in very dynamic environments where tight
>>>coupling
>>> > is desirable between SPF compute and FIB update. In scaled
>>>environments the
>>> > issue is less about SPF compute time and is more about synchronizing
>>>the
>>> > FIB.
>>> >
>>> > Running on-demand CSPF by IRS application may be fine because of
>>> > persistency of RSVP-TE tunnels in dynamic environments.
>>> >
>>> > I apologize if I misunderstood the intent.
>>> >
>>> > Thanks,
>>> > Pranjal
>>>
>>> ---snip---
>>>
>>> _______________________________________________
>>> 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, 30 Aug 2012 23:43:21 -0400
From: Alia Atlas <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: David Meyer <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

On the encap/decap, I certainly view encap as simply a different type
of next-hop that a route to the RIB can have.  Similarly, one can view
decap as treating a particular label/prefix - though that may require
more complexity.

Negotiation is another area to think about too.  Clearly, there will
be some capability negotiation needed as part of IRS - as well as the
ability to query for what capabilities are supported by the routing
element.

Incidentally, if you are interested in writing down your thoughts
around different architectures for where parts of the routing system
might live and how they should/would interact with IRS, I'd encourage
you to do so and to chat with Dave Meyer, who has agreed to take on
looking at such pieces.

While I do think that migrating the entire routing system except for
RIB off of a routing element would be for rather specialized
environments, I am also concerned that we consider the different
architectural possibilities when defining IRS so that we don't end up
going down an insufficient path.

Alia

On Thu, Aug 30, 2012 at 9:16 PM, Edward Crabbe <[email-masked]> wrote:
> Yep;  not having to run an IGP on the box, which is great for those people
> not wanting / needing core internet protocols on their devices.  The
> standard set of 'SDN' talking appoints applies here in terms of development
> speed, performance improvements resulting from use of modern commodity
> compute, friendliness of development environment, potential for decreased
> bug count* etc etc.
>
> It's a specialized use case, but it exists.
>
> However, my fundamental point is that with IRS as defined currently (ie PBR
> with extensible match fields on on RIB recursion + additional monitoring and
> data collection hooks) you can do hypothetically do away with IGPs.  Indeed,
> assuming that the encaps is applied at some other device (since IRS as
> currently described doesn't account for encap/decap application or
> negotiation functionality)  you can effectively replace a significant number
> of protocols (including stateful PCE) should you want to.   :P
>
> <can of worms>
>
> *The benefits in terms of decreased bug counts above is really varies with
> how complex we make IRS of course.
>
> On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal)
> <[email-masked]> wrote:
>>
>> Yep, the context of our original discussion was never PCE as we understand
>> its CSPF or some form like that. Our concern was – is there a strong use
>>
>> case for non-constrained SPF?
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Thursday, August 30, 2012 5:34 PM
>>
>>
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Nope, not specifically, but it strongly implies that there is some form of
>> SPF running given the use of constraints in the draft.
>>
>> On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>>
>> That doesn’t talk about centralized SPF, does it ?
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Thursday, August 30, 2012 4:12 PM
>>
>>
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01
>>
>> On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>>
>> ‘operational model’ = IETF draft that describes the use case.
>>
>> ‘large’ = 40K LSAs, 500 IGP nodes.
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Thursday, August 30, 2012 2:44 PM
>>
>>
>> To: Dutta, Pranjal K (Pranjal)
>>
>> Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> please define 'operational model' ( and 'large' :) .
>>
>> On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>>
>> Hi,
>>
>>          I believe that’s 10% of what overall work that router does today
>> w.r.t routing. I would like to see an operational model how such centralized
>> SPF can
>>
>> provide end-to-end convergence of large number of flows efficiently.
>>
>>
>>
>> Thanks,
>>
>> Pranjal
>>
>>
>>
>> ________________________________
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Thursday, August 30, 2012 11:59 AM
>> To: Alia Atlas
>> Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu;
>> [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Alia;
>>
>>
>>
>> If there is
>>
>>
>>
>> a) a mechanism for installing routes, pbr or otherwise, which recurse to
>> directly connected nexthops
>>
>> b) a mechanism for gathering topological information
>>
>>
>>
>> then you've inherently enabled centralized spf.
>>
>>
>>
>> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:
>>
>> I haven't seen a good description of what is intended or desired by
>> moving the SPF functionality to a centralized location.  Clearly such
>> centralization can have a very bad impact on convergence - which is a
>> strong motivator for simultaneously computing fast-reroute
>> alternatives (with guaranteed coverage ala MRT) and installing both.
>>
>> I don't see IRS as having a way of "turning off" the SPF computation
>> in the IGP; a different lobotomized IGP protocol/process would be
>> needed.
>>
>> Alia
>>
>>
>> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>> > "LSDB (I saw an email which talks about reducing IGP to link
>> >> distribution protocol and running SPF in centralized network
>> >> controller)"
>> >
>> > I have seen discussions in the past on this and in fact I didn't get
>> > precisely what is meant. If anybody in the list could brief very
>> > precisely that would help a lot.
>> >
>> > Here is my understanding - the routers would do LSA/LSP flooding for
>> > OSPF/ISIS as it is done today. So routers would build neighboring
>> > relationship/adjacencies to participate in flooding and each router builds
>> > its LSDB.
>> >
>> > Then the IRS "application" would track LSDB changes and pull up the
>> > "diffs" from each router (thru "controller") whenever there is a change. The
>> > application would compute SPF on behalf of each router (LSDB). The result of
>> > the compute would be pushed by application to each Router (thru controller)
>> > and inject entries into RIB.
>> >
>> > Is that correct? How different this going to be from PCE?
>> >
>> > If this is correct then perhaps we would like to ask what are the
>> > scalability numbers in LSDB we are talking about?
>> >
>> > The "application" would be running in a high performance server and so
>> > SPF compute there is not an issue and perhaps it is good way to synchronize
>> > FIB update (to a certain extent) to avoid u-loops etc.
>> >
>> > But when we are managing all routers in the purview of the application,
>> > the computing power in each router is not uniform. To be realistic, I have
>> > some concerns on how much "real-timeness" we could achieve between
>> > application and controllers on such proposals, esp. when scaling numbers are
>> > high. This leads to higher time lag on inconsistency between application SPF
>> > compute and FIB update. It's almost like the classic "slow peering" issues
>> > with TCP like protocols - the high performance peer is slowed down by low
>> > performance peer.
>> >
>> > Static route interface is good thing because it is a state that persists
>> > longer.
>> >
>> > IGPs may be deployed in very dynamic environments where tight coupling
>> > is desirable between SPF compute and FIB update. In scaled environments the
>> > issue is less about SPF compute time and is more about synchronizing the
>> > FIB.
>> >
>> > Running on-demand CSPF by IRS application may be fine because of
>> > persistency of RSVP-TE tunnels in dynamic environments.
>> >
>> > I apologize if I misunderstood the intent.
>> >
>> > Thanks,
>> > Pranjal
>>
>> ---snip---
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
>>
>>
>>
>>
>
>

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Edward Crabbe <[email-masked]>
Date: Fri, 31 Aug 2012 08:33:25 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah,  Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

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

I can understand about very specialized use cases in closed environments but IMO, too much emphasis has been given
on power of central compute but still has to deal with "unfriendly" routers for FIB convergence and synchronization..on
theory, yes there is absolutely no problem for real-time applications :).

________________________________
From: Edward Crabbe [mailto:[email-masked]]
Sent: Thursday, August 30, 2012 6:16 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Yep;  not having to run an IGP on the box, which is great for those people not wanting / needing core internet protocols on their devices.  The standard set of 'SDN' talking appoints applies here in terms of development speed, performance improvements resulting from use of modern commodity compute, friendliness of development environment, potential for decreased bug count* etc etc.

It's a specialized use case, but it exists.

However, my fundamental point is that with IRS as defined currently (ie PBR with extensible match fields on on RIB recursion + additional monitoring and data collection hooks) you can do hypothetically do away with IGPs.  Indeed, assuming that the encaps is applied at some other device (since IRS as currently described doesn't account for encap/decap application or negotiation functionality)  you can effectively replace a significant number of protocols (including stateful PCE) should you want to.   :P

<can of worms>

*The benefits in terms of decreased bug counts above is really varies with how complex we make IRS of course.

On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
Yep, the context of our original discussion was never PCE as we understand its CSPF or some form like that. Our concern was - is there a strong use
case for non-constrained SPF?

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 5:34 PM

To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Nope, not specifically, but it strongly implies that there is some form of SPF running given the use of constraints in the draft.
On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
That doesn't talk about centralized SPF, does it ?

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 4:12 PM

To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>
Subject: Re: [irs-discuss] IRS comments

http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01
On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
'operational model' = IETF draft that describes the use case.
'large' = 40K LSAs, 500 IGP nodes.

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 2:44 PM

To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

please define 'operational model' ( and 'large' :) .
On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
         I believe that's 10% of what overall work that router does today w.r.t routing. I would like to see an operational model how such centralized SPF can
provide end-to-end convergence of large number of flows efficiently.

Thanks,
Pranjal

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

Alia;

If there is

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops
b) a mechanism for gathering topological information

then you've inherently enabled centralized spf.

On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
I haven't seen a good description of what is intended or desired by
moving the SPF functionality to a centralized location.  Clearly such
centralization can have a very bad impact on convergence - which is a
strong motivator for simultaneously computing fast-reroute
alternatives (with guaranteed coverage ala MRT) and installing both.

I don't see IRS as having a way of "turning off" the SPF computation
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia

On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]<mailto:[email-masked]>> wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
>
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>
> If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.
>
> But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persists longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.
>
> Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.
>
> I apologize if I misunderstood the intent.
>
> Thanks,
> Pranjal
---snip---
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C8B2INBANSXCHMBSA_
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="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I can understand about very specialized
use cases in closed environments but IMO, too much emphasis has been given <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>on power of central compute but still has
to deal with &#8220;unfriendly&#8221; routers for FIB convergence and synchronization..on <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>theory, yes there is absolutely no problem
for real-time applications </span></font><font size=2 color=navy
face=Wingdings><span style='font-size:10.0pt;font-family:Wingdings;color:navy'>J</span></font><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</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=3 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'> Edward Crabbe
[mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
6:16 PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> Alia Atlas; UTTARO, JAMES; <st1:PersonName
w:st="on">Shah, Himanshu</st1:PersonName>; <st1:PersonName w:st="on">[email-masked]</st1:PersonName><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</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>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Yep; &nbsp;not having to run an IGP on the box, which is great for
those people not wanting / needing core internet protocols on their devices.
&nbsp;The standard set of 'SDN' talking appoints applies here in terms of
development speed, performance improvements resulting from use of modern
commodity compute,&nbsp;friendliness&nbsp;of development environment, potential
for decreased bug count* etc etc. &nbsp;<o:p></o:p></span></font></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>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>It's a specialized use case, but it exists.&nbsp;<o:p></o:p></span></font></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>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>However, my fundamental point is that with IRS as
defined&nbsp;currently&nbsp;(ie PBR with extensible match fields on on RIB
recursion + additional monitoring and data collection hooks) you can do
hypothetically do away with IGPs. &nbsp;Indeed, assuming that the encaps is
applied at some other device (since IRS as currently described doesn't account
for encap/decap application or negotiation functionality) &nbsp;you can
effectively replace a significant number of protocols (including stateful PCE)
should you want to. &nbsp; :P<o:p></o:p></span></font></p>

</div>

<div>

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

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&lt;can of worms&gt;&nbsp;<o:p></o:p></span></font></p>

</div>

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

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>*The benefits in terms of decreased bug counts above is really varies
with how complex we make IRS of course. &nbsp;&nbsp;<o:p></o:p></span></font></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=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Aug 30, 2012 at 6:01 PM, <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal) &lt;<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Yep, the context of our original discussion was never PCE as we
understand its CSPF or some form like that. Our concern was &#8211; is there a strong
use</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>case for non-constrained SPF? &nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
5:34 PM</span></font><o:p></o:p></p>

<div>

<div>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> Alia Atlas; UTTARO, JAMES; <st1:PersonName
w:st="on">Shah, Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>Nope, not
specifically, but it strongly implies that there is some form of SPF running
given the use of constraints in the draft. &nbsp;&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 30,
2012 at 4:16 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>That doesn&#8217;t talk about centralized SPF, does it ?</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
4:12 PM</span></font><o:p></o:p></p>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> Alia Atlas; UTTARO, JAMES; <st1:PersonName
w:st="on">Shah, Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><a
href="http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01" target="_blank">http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01</a><o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 30,
2012 at 4:09 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&#8216;operational model&#8217; = IETF draft that describes the use case.</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&#8216;large&#8217; = 40K LSAs, 500 IGP nodes.</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
2:44 PM</span></font><o:p></o:p></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma;font-weight:
bold'>Cc:</span></font></b><font face=Tahoma><span style='font-family:Tahoma'>
Alia Atlas; UTTARO, JAMES; <st1:PersonName w:st="on">Shah, Himanshu</st1:PersonName>;
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></font><o:p></o:p></p>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>please define
'operational model' ( and 'large' :) . &nbsp;<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 30,
2012 at 1:40 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Hi,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I believe that&#8217;s
10% of what overall work that router does today w.r.t routing. I would like to
see an operational model how such centralized SPF can </span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>provide end-to-end convergence of large number of flows efficiently.
</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Thanks,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Pranjal</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Alia Atlas<br>
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal); UTTARO, JAMES; <st1:PersonName w:st="on">Shah,
 Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a></span></font><o:p></o:p></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>Alia;<o:p></o:p></span></font></p>

<div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>If there is&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>a) a mechanism for
installing routes, pbr or otherwise, which recurse to directly connected
nexthops<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>b) a mechanism for
gathering topological information<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>then you've
inherently enabled centralized spf.&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 16,
2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]"
target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>I haven't seen a
good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location. &nbsp;Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don't see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><br>
On Thu, Aug 16, 2012 at 12:14 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn't get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It's almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue
is less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<o:p></o:p></span></font></p>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>---snip---<o:p></o:p></span></font></p>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></span></font></p>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

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

</div>

</div>

</div>

</div>

</body>

</html>

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C8B2INBANSXCHMBSA_--

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 18:16:11 -0700
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--bcaec529972f00a79204c8858c20
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yep;  not having to run an IGP on the box, which is great for those people
not wanting / needing core internet protocols on their devices.  The
standard set of 'SDN' talking appoints applies here in terms of development
speed, performance improvements resulting from use of modern commodity
compute, friendliness of development environment, potential for decreased
bug count* etc etc.

It's a specialized use case, but it exists.

However, my fundamental point is that with IRS as defined currently (ie PBR
with extensible match fields on on RIB recursion + additional monitoring
and data collection hooks) you can do hypothetically do away with IGPs.
 Indeed, assuming that the encaps is applied at some other device (since
IRS as currently described doesn't account for encap/decap application or
negotiation functionality)  you can effectively replace a significant
number of protocols (including stateful PCE) should you want to.   :P

<can of worms>

*The benefits in terms of decreased bug counts above is really varies with
how complex we make IRS of course.

On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal) <
[email-masked]> wrote:

> **
>
> Yep, the context of our original discussion was never PCE as we understand
> its CSPF or some form like that. Our concern was – is there a strong use**
> **
>
> case for non-constrained SPF?  ****
>
> ** **
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 5:34 PM
>
> *To:* **Dutta, Pranjal K** (Pranjal)
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; **
> [email-masked]**
> *Subject:* Re: [irs-discuss] IRS comments
> ****
>
>  ** **
>
> Nope, not specifically, but it strongly implies that there is some form of
> SPF running given the use of constraints in the draft.   ****
>
> On Thu, Aug 30, 2012 at 4:16 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> That doesn’t talk about centralized SPF, does it ?****
>
>  ****
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 4:12 PM****
>
>
> *To:* **Dutta, Pranjal K** (Pranjal)
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; [email-masked]
> *Subject:* Re: [irs-discuss] IRS comments****
>
>  ****
>
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01****
>
> On Thu, Aug 30, 2012 at 4:09 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> ‘operational model’ = IETF draft that describes the use case.****
>
> ‘large’ = 40K LSAs, 500 IGP nodes.****
>
>  ****
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 2:44 PM****
>
>
> *To:* **Dutta, Pranjal K** (Pranjal)****
>
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; [email-masked]*
> ***
>
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
>  ****
>
> please define 'operational model' ( and 'large' :) .  ****
>
> On Thu, Aug 30, 2012 at 1:40 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> Hi,****
>
>          I believe that’s 10% of what overall work that router does today
> w.r.t routing. I would like to see an operational model how such
> centralized SPF can ****
>
> provide end-to-end convergence of large number of flows efficiently. ****
>
>  ****
>
> Thanks,****
>
> Pranjal****
>
>  ****
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 11:59 AM
> *To:* Alia Atlas
> *Cc:* **Dutta, Pranjal K** (Pranjal); UTTARO, JAMES; **Shah, Himanshu**;
> [email-masked]****
>
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
>  ****
>
> Alia;****
>
>  ****
>
> If there is ****
>
>  ****
>
> a) a mechanism for installing routes, pbr or otherwise, which recurse to
> directly connected nexthops****
>
> b) a mechanism for gathering topological information****
>
>  ****
>
> then you've inherently enabled centralized spf. ****
>
>  ****
>
> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:****
>
> I haven't seen a good description of what is intended or desired by
> moving the SPF functionality to a centralized location.  Clearly such
> centralization can have a very bad impact on convergence - which is a
> strong motivator for simultaneously computing fast-reroute
> alternatives (with guaranteed coverage ala MRT) and installing both.
>
> I don't see IRS as having a way of "turning off" the SPF computation
> in the IGP; a different lobotomized IGP protocol/process would be
> needed.
>
> Alia****
>
>
> On Thu, Aug 16, 2012 at 12:14 PM, **Dutta, Pranjal K** (Pranjal)
> <[email-masked]> wrote:
> > "LSDB (I saw an email which talks about reducing IGP to link
> >> distribution protocol and running SPF in centralized network
> >> controller)"
> >
> > I have seen discussions in the past on this and in fact I didn't get
> precisely what is meant. If anybody in the list could brief very
> > precisely that would help a lot.
> >
> > Here is my understanding - the routers would do LSA/LSP flooding for
> OSPF/ISIS as it is done today. So routers would build neighboring
> relationship/adjacencies to participate in flooding and each router builds
> its LSDB.
> >
> > Then the IRS "application" would track LSDB changes and pull up the
> "diffs" from each router (thru "controller") whenever there is a change.
> The application would compute SPF on behalf of each router (LSDB). The
> result of the compute would be pushed by application to each Router (thru
> controller) and inject entries into RIB.
> >
> > Is that correct? How different this going to be from PCE?
> >
> > If this is correct then perhaps we would like to ask what are the
> scalability numbers in LSDB we are talking about?
> >
> > The "application" would be running in a high performance server and so
> SPF compute there is not an issue and perhaps it is good way to synchronize
> FIB update (to a certain extent) to avoid u-loops etc.
> >
> > But when we are managing all routers in the purview of the application,
> the computing power in each router is not uniform. To be realistic, I have
> some concerns on how much "real-timeness" we could achieve between
> application and controllers on such proposals, esp. when scaling numbers
> are high. This leads to higher time lag on inconsistency between
> application SPF compute and FIB update. It's almost like the classic "slow
> peering" issues with TCP like protocols - the high performance peer is
> slowed down by low performance peer.
> >
> > Static route interface is good thing because it is a state that persists
> longer.
> >
> > IGPs may be deployed in very dynamic environments where tight coupling
> is desirable between SPF compute and FIB update. In scaled environments the
> issue is less about SPF compute time and is more about synchronizing the
> FIB.
> >
> > Running on-demand CSPF by IRS application may be fine because of
> persistency of RSVP-TE tunnels in dynamic environments.
> >
> > I apologize if I misunderstood the intent.
> >
> > Thanks,
> > Pranjal****
>
> ---snip---****
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>

--bcaec529972f00a79204c8858c20
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Yep;  not having to run an IGP on the box, which is great for those people not wanting / needing core internet protocols on their devices.  The standard set of &#39;SDN&#39; talking appoints applies here in terms of development speed, performance improvements resulting from use of modern commodity compute, friendliness of development environment, potential for decreased bug count* etc etc.  <div>

<br></div><div>It&#39;s a specialized use case, but it exists. <div><br></div><div>However, my fundamental point is that with IRS as defined currently (ie PBR with extensible match fields on on RIB recursion + additional monitoring and data collection hooks) you can do hypothetically do away with IGPs.  Indeed, assuming that the encaps is applied at some other device (since IRS as currently described doesn&#39;t account for encap/decap application or negotiation functionality)  you can effectively replace a significant number of protocols (including stateful PCE) should you want to.   :P</div>

<div><div><br></div><div>&lt;can of worms&gt; </div><div><br></div><div>*The benefits in terms of decreased bug counts above is really varies with how complex we make IRS of course.   <div><br><div class="gmail_quote">On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal) <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">

<u></u>

<div lang="EN-US" link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Yep, the context of our original
discussion was never PCE as we understand its CSPF or some form like that. Our
concern was – is there a strong use<u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">case for non-constrained SPF?  <u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe
[mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
5:34 PM</span></font></p><div><div><font face="Tahoma"><br>
<b><span style="font-weight:bold">To:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal)<br>
<b><span style="font-weight:bold">Cc:</span></b> Alia Atlas; UTTARO, JAMES; <u></u>Shah, Himanshu<u></u>; <u></u><a href="mailto:[email-masked]" target="_blank">[email-masked]</a><u></u><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</font></div></div><u></u><u></u><p></p>

</div><div><div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">Nope, not specifically,
but it strongly implies that there is some form of SPF running given the use of
constraints in the draft.   <u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 30, 2012 at 4:16 PM, <u></u>Dutta,
 Pranjal K<u></u> (Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<u></u><u></u></span></font></p>

<div link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">That doesn’t talk about centralized SPF, does it ?</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
4:12 PM</span></font><u></u><u></u></p>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">To:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal)<br>
<b><span style="font-weight:bold">Cc:</span></b> Alia Atlas; UTTARO, JAMES; <u></u>Shah, Himanshu<u></u>; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><u></u><u></u></p>

</div>

</div>

</div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><a href="http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01" target="_blank">http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01</a><u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 30,
2012 at 4:09 PM, <u></u>Dutta, Pranjal K<u></u>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<u></u><u></u></span></font></p>

<div link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">‘operational model’ = IETF draft that describes the use case.</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">‘large’ = 40K LSAs, 500 IGP nodes.</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
2:44 PM</span></font><u></u><u></u></p>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">To:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal)</span></font><u></u><u></u></p>

</div>

<p class="MsoNormal"><b><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma;font-weight:bold">Cc:</span></font></b><font face="Tahoma"><span style="font-family:Tahoma">
Alia Atlas; UTTARO, JAMES; <u></u>Shah, Himanshu<u></u>;
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></font><u></u><u></u></p>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><u></u><u></u></p>

</div>

</div>

</div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">please define
&#39;operational model&#39; ( and &#39;large&#39; :) .  <u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 30,
2012 at 1:40 PM, <u></u>Dutta, Pranjal K<u></u>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<u></u><u></u></span></font></p>

<div link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Hi,</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">         I believe that’s
10% of what overall work that router does today w.r.t routing. I would like to
see an operational model how such centralized SPF can </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">provide end-to-end convergence of large number of flows
efficiently. </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Thanks,</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Pranjal</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style="font-weight:bold">To:</span></b> Alia Atlas<br>
<b><span style="font-weight:bold">Cc:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal); UTTARO, JAMES; <u></u>Shah,
 Himanshu<u></u>; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></font><u></u><u></u></p>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><u></u><u></u></p>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">Alia;<u></u><u></u></span></font></p>

<div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">If there is <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">a) a mechanism for
installing routes, pbr or otherwise, which recurse to directly connected
nexthops<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">b) a mechanism for
gathering topological information<u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">then you&#39;ve
inherently enabled centralized spf. <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 16,
2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">I haven&#39;t seen a
good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location.  Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don&#39;t see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><br>
On Thu, Aug 16, 2012 at 12:14 PM, <u></u>Dutta, Pranjal K<u></u>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn&#39;t get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It&#39;s almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue is
less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<u></u><u></u></span></font></p>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">---snip---<u></u><u></u></span></font></p>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><u></u><u></u></span></font></p>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

</div>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

</div>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div></div></div>

</div>

</blockquote></div><br></div></div></div></div>

--bcaec529972f00a79204c8858c20--

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Edward Crabbe <[email-masked]>
Date: Fri, 31 Aug 2012 06:31:15 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah,  Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

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

Yep, the context of our original discussion was never PCE as we understand its CSPF or some form like that. Our concern was - is there a strong use
case for non-constrained SPF?

________________________________
From: Edward Crabbe [mailto:[email-masked]]
Sent: Thursday, August 30, 2012 5:34 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Nope, not specifically, but it strongly implies that there is some form of SPF running given the use of constraints in the draft.
On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
That doesn't talk about centralized SPF, does it ?

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 4:12 PM

To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>
Subject: Re: [irs-discuss] IRS comments

http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01
On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
'operational model' = IETF draft that describes the use case.
'large' = 40K LSAs, 500 IGP nodes.

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 2:44 PM

To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

please define 'operational model' ( and 'large' :) .
On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
         I believe that's 10% of what overall work that router does today w.r.t routing. I would like to see an operational model how such centralized SPF can
provide end-to-end convergence of large number of flows efficiently.

Thanks,
Pranjal

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

Alia;

If there is

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops
b) a mechanism for gathering topological information

then you've inherently enabled centralized spf.

On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
I haven't seen a good description of what is intended or desired by
moving the SPF functionality to a centralized location.  Clearly such
centralization can have a very bad impact on convergence - which is a
strong motivator for simultaneously computing fast-reroute
alternatives (with guaranteed coverage ala MRT) and installing both.

I don't see IRS as having a way of "turning off" the SPF computation
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia

On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]<mailto:[email-masked]>> wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
>
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>
> If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.
>
> But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persists longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.
>
> Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.
>
> I apologize if I misunderstood the intent.
>
> Thanks,
> Pranjal
---snip---
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C8ADINBANSXCHMBSA_
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="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Yep, the context of our original
discussion was never PCE as we understand its CSPF or some form like that. Our
concern was &#8211; is there a strong use<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>case for non-constrained SPF? &nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</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=3 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'> Edward Crabbe
[mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
5:34 PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> Alia Atlas; UTTARO, JAMES; <st1:PersonName
w:st="on">Shah, Himanshu</st1:PersonName>; <st1:PersonName w:st="on">[email-masked]</st1:PersonName><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</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>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>Nope, not specifically,
but it strongly implies that there is some form of SPF running given the use of
constraints in the draft. &nbsp;&nbsp;<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Aug 30, 2012 at 4:16 PM, <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal) &lt;<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>That doesn&#8217;t talk about centralized SPF, does it ?</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
4:12 PM</span></font><o:p></o:p></p>

<div>

<div>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> Alia Atlas; UTTARO, JAMES; <st1:PersonName
w:st="on">Shah, Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><a
href="http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01" target="_blank">http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01</a><o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 30,
2012 at 4:09 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&#8216;operational model&#8217; = IETF draft that describes the use case.</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&#8216;large&#8217; = 40K LSAs, 500 IGP nodes.</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
2:44 PM</span></font><o:p></o:p></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma;font-weight:
bold'>Cc:</span></font></b><font face=Tahoma><span style='font-family:Tahoma'>
Alia Atlas; UTTARO, JAMES; <st1:PersonName w:st="on">Shah, Himanshu</st1:PersonName>;
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></font><o:p></o:p></p>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>please define
'operational model' ( and 'large' :) . &nbsp;<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 30,
2012 at 1:40 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Hi,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I believe that&#8217;s
10% of what overall work that router does today w.r.t routing. I would like to
see an operational model how such centralized SPF can </span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>provide end-to-end convergence of large number of flows
efficiently. </span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Thanks,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Pranjal</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Alia Atlas<br>
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal); UTTARO, JAMES; <st1:PersonName w:st="on">Shah,
 Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a></span></font><o:p></o:p></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>Alia;<o:p></o:p></span></font></p>

<div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>If there is&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>a) a mechanism for
installing routes, pbr or otherwise, which recurse to directly connected
nexthops<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>b) a mechanism for
gathering topological information<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>then you've
inherently enabled centralized spf.&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 16,
2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]"
target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>I haven't seen a
good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location. &nbsp;Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don't see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><br>
On Thu, Aug 16, 2012 at 12:14 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn't get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It's almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue is
less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<o:p></o:p></span></font></p>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>---snip---<o:p></o:p></span></font></p>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></span></font></p>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

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

</body>

</html>

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C8ADINBANSXCHMBSA_--

References: <[email-masked]> <CAG=[email-masked]> <[email-masked]> <CAG=[email-masked]> <CAG4d1rd_p6x_+PsHWtsYU=[email-masked]> <[email-masked]> <CAG4d1reWGjUU-z=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CACKN6JFMZqOnHU=vEkx8WxwSLjg5MYY=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAG4d1rfEkxAu_XbeVN_76mw+=[email-masked]> <CACKN6JFNHSM=Tu=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CACKN6JELp0rNN60z4b0Xf1xhRnVhSqHcU64wrD=[email-masked]> <[email-masked]>
From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 17:33:46 -0700
Message-ID: <[email-masked]>
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Content-Type: multipart/alternative; boundarydae9340d076077ec04c884f457
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQmFTWOth7prKf4yULvuQKuYgNd5E817sNM7Prb79Iv6Ca7Xjq8/MSaSdSbamKffznlSGtTpLVxGqR6XA4rfbw7Ujq4AfTKFlWWQqMkLaK51W0Cf4HpcAeSNLM7HCqkBdxa/5ElfX6cLBFWubXWDaI3e7VddSebudJBhdh6HkE4tTt5+ioLp2b70er646klu3g4UyDFj
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Fri, 31 Aug 2012 00:34:30 -0000

--14dae9340d076077ec04c884f457
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Nope, not specifically, but it strongly implies that there is some form of
SPF running given the use of constraints in the draft.

On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal) <
[email-masked]> wrote:

> **
>
> That doesn’t talk about centralized SPF, does it ?****
>
> ** **
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 4:12 PM
>
> *To:* **Dutta, Pranjal K** (Pranjal)
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; **
> [email-masked]**
> *Subject:* Re: [irs-discuss] IRS comments
> ****
>
>  ** **
>
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01****
>
> On Thu, Aug 30, 2012 at 4:09 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> ‘operational model’ = IETF draft that describes the use case.****
>
> ‘large’ = 40K LSAs, 500 IGP nodes.****
>
>  ****
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 2:44 PM****
>
>
> *To:* **Dutta, Pranjal K** (Pranjal)****
>
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; [email-masked]*
> ***
>
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
>  ****
>
> please define 'operational model' ( and 'large' :) .  ****
>
> On Thu, Aug 30, 2012 at 1:40 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> Hi,****
>
>          I believe that’s 10% of what overall work that router does today
> w.r.t routing. I would like to see an operational model how such
> centralized SPF can ****
>
> provide end-to-end convergence of large number of flows efficiently. ****
>
>  ****
>
> Thanks,****
>
> Pranjal****
>
>  ****
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 11:59 AM
> *To:* Alia Atlas
> *Cc:* **Dutta, Pranjal K** (Pranjal); UTTARO, JAMES; **Shah, Himanshu**;
> [email-masked]****
>
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
>  ****
>
> Alia;****
>
>  ****
>
> If there is ****
>
>  ****
>
> a) a mechanism for installing routes, pbr or otherwise, which recurse to
> directly connected nexthops****
>
> b) a mechanism for gathering topological information****
>
>  ****
>
> then you've inherently enabled centralized spf. ****
>
>  ****
>
> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:****
>
> I haven't seen a good description of what is intended or desired by
> moving the SPF functionality to a centralized location.  Clearly such
> centralization can have a very bad impact on convergence - which is a
> strong motivator for simultaneously computing fast-reroute
> alternatives (with guaranteed coverage ala MRT) and installing both.
>
> I don't see IRS as having a way of "turning off" the SPF computation
> in the IGP; a different lobotomized IGP protocol/process would be
> needed.
>
> Alia****
>
>
> On Thu, Aug 16, 2012 at 12:14 PM, **Dutta, Pranjal K** (Pranjal)
> <[email-masked]> wrote:
> > "LSDB (I saw an email which talks about reducing IGP to link
> >> distribution protocol and running SPF in centralized network
> >> controller)"
> >
> > I have seen discussions in the past on this and in fact I didn't get
> precisely what is meant. If anybody in the list could brief very
> > precisely that would help a lot.
> >
> > Here is my understanding - the routers would do LSA/LSP flooding for
> OSPF/ISIS as it is done today. So routers would build neighboring
> relationship/adjacencies to participate in flooding and each router builds
> its LSDB.
> >
> > Then the IRS "application" would track LSDB changes and pull up the
> "diffs" from each router (thru "controller") whenever there is a change.
> The application would compute SPF on behalf of each router (LSDB). The
> result of the compute would be pushed by application to each Router (thru
> controller) and inject entries into RIB.
> >
> > Is that correct? How different this going to be from PCE?
> >
> > If this is correct then perhaps we would like to ask what are the
> scalability numbers in LSDB we are talking about?
> >
> > The "application" would be running in a high performance server and so
> SPF compute there is not an issue and perhaps it is good way to synchronize
> FIB update (to a certain extent) to avoid u-loops etc.
> >
> > But when we are managing all routers in the purview of the application,
> the computing power in each router is not uniform. To be realistic, I have
> some concerns on how much "real-timeness" we could achieve between
> application and controllers on such proposals, esp. when scaling numbers
> are high. This leads to higher time lag on inconsistency between
> application SPF compute and FIB update. It's almost like the classic "slow
> peering" issues with TCP like protocols - the high performance peer is
> slowed down by low performance peer.
> >
> > Static route interface is good thing because it is a state that persists
> longer.
> >
> > IGPs may be deployed in very dynamic environments where tight coupling
> is desirable between SPF compute and FIB update. In scaled environments the
> issue is less about SPF compute time and is more about synchronizing the
> FIB.
> >
> > Running on-demand CSPF by IRS application may be fine because of
> persistency of RSVP-TE tunnels in dynamic environments.
> >
> > I apologize if I misunderstood the intent.
> >
> > Thanks,
> > Pranjal****
>
> ---snip---****
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
>  ****
>
>  ****
>
> ** **
>

--14dae9340d076077ec04c884f457
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Nope, not specifically, but it strongly implies that there is some form of SPF running given the use of constraints in the draft.   <br><br><div class="gmail_quote">On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal) <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">

<u></u>

<div lang="EN-US" link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">That doesn’t talk about centralized SPF,
does it ?<u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe
[mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
4:12 PM</span></font></p><div><div class="h5"><font face="Tahoma"><br>
<b><span style="font-weight:bold">To:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal)<br>
<b><span style="font-weight:bold">Cc:</span></b> Alia Atlas; UTTARO, JAMES; <u></u>Shah, Himanshu<u></u>; <u></u><a href="mailto:[email-masked]" target="_blank">[email-masked]</a><u></u><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</font></div></div><u></u><u></u><p></p>

</div><div><div class="h5">

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><a href="http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01" target="_blank">http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01</a><u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 30, 2012 at 4:09 PM, <u></u>Dutta,
 Pranjal K<u></u> (Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<u></u><u></u></span></font></p>

<div link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">‘operational model’ = IETF draft that describes the use case.</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">‘large’ = 40K LSAs, 500 IGP nodes.</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
2:44 PM</span></font><u></u><u></u></p>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">To:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal)</span></font><u></u><u></u></p>

</div>

<p class="MsoNormal"><b><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma;font-weight:bold">Cc:</span></font></b><font face="Tahoma"><span style="font-family:Tahoma"> Alia Atlas; UTTARO, JAMES; <u></u>Shah,
 Himanshu<u></u>; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><u></u><u></u></span></font></p>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments<u></u><u></u></span></font></p>

</div>

</div>

</div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">please define
&#39;operational model&#39; ( and &#39;large&#39; :) .  <u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 30,
2012 at 1:40 PM, <u></u>Dutta, Pranjal K<u></u>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<u></u><u></u></span></font></p>

<div link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Hi,</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">         I believe that’s
10% of what overall work that router does today w.r.t routing. I would like to
see an operational model how such centralized SPF can </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">provide end-to-end convergence of large number of flows
efficiently. </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Thanks,</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Pranjal</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style="font-weight:bold">To:</span></b> Alia Atlas<br>
<b><span style="font-weight:bold">Cc:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal); UTTARO, JAMES; <u></u>Shah,
 Himanshu<u></u>; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></font><u></u><u></u></p>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><u></u><u></u></p>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">Alia;<u></u><u></u></span></font></p>

<div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">If there is <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">a) a mechanism for
installing routes, pbr or otherwise, which recurse to directly connected
nexthops<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">b) a mechanism for
gathering topological information<u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">then you&#39;ve
inherently enabled centralized spf. <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 16,
2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">I haven&#39;t seen a
good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location.  Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don&#39;t see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><br>
On Thu, Aug 16, 2012 at 12:14 PM, <u></u>Dutta, Pranjal K<u></u>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn&#39;t get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It&#39;s almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue
is less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<u></u><u></u></span></font></p>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">---snip---<u></u><u></u></span></font></p>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><u></u><u></u></span></font></p>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

</div>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div></div></div>

</div>

</blockquote></div><br>

--14dae9340d076077ec04c884f457--

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Edward Crabbe <[email-masked]>
Date: Fri, 31 Aug 2012 04:46:15 +0530
References: <[email-masked]> <CAG=[email-masked]> <[email-masked]> <CAG=[email-masked]> <CAG4d1rd_p6x_+PsHWtsYU=[email-masked]> <[email-masked]> <CAG4d1reWGjUU-z=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CACKN6JFMZqOnHU=vEkx8WxwSLjg5MYY=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CAG4d1rfEkxAu_XbeVN_76mw+=[email-masked]> <CACKN6JFNHSM=Tu=[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <CACKN6JELp0rNN60z4b0Xf1xhRnVhSqHcU64wrD=[email-masked]>
In-Reply-To: <CACKN6JELp0rNN60z4b0Xf1xhRnVhSqHcU64wrD=[email-masked]>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_C584046466ED224CA92C1BC3313B963E13F0B8C89FINBANSXCHMBSA_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah,  Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments
X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Thu, 30 Aug 2012 23:16:30 -0000

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

That doesn't talk about centralized SPF, does it ?

________________________________
From: Edward Crabbe [mailto:[email-masked]]
Sent: Thursday, August 30, 2012 4:12 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
Subject: Re: [irs-discuss] IRS comments

http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01
On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
'operational model' = IETF draft that describes the use case.
'large' = 40K LSAs, 500 IGP nodes.

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 2:44 PM

To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

please define 'operational model' ( and 'large' :) .
On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
         I believe that's 10% of what overall work that router does today w.r.t routing. I would like to see an operational model how such centralized SPF can
provide end-to-end convergence of large number of flows efficiently.

Thanks,
Pranjal

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

Alia;

If there is

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops
b) a mechanism for gathering topological information

then you've inherently enabled centralized spf.

On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
I haven't seen a good description of what is intended or desired by
moving the SPF functionality to a centralized location.  Clearly such
centralization can have a very bad impact on convergence - which is a
strong motivator for simultaneously computing fast-reroute
alternatives (with guaranteed coverage ala MRT) and installing both.

I don't see IRS as having a way of "turning off" the SPF computation
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia

On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]<mailto:[email-masked]>> wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
>
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>
> If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.
>
> But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persists longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.
>
> Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.
>
> I apologize if I misunderstood the intent.
>
> Thanks,
> Pranjal
---snip---
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C89FINBANSXCHMBSA_
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="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>That doesn&#8217;t talk about centralized SPF,
does it ?<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</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=3 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'> Edward Crabbe
[mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
4:12 PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> Alia Atlas; UTTARO, JAMES; <st1:PersonName
w:st="on">Shah, Himanshu</st1:PersonName>; <st1:PersonName w:st="on">[email-masked]</st1:PersonName><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</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>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'><a
href="http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01">http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01</a><o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Aug 30, 2012 at 4:09 PM, <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal) &lt;<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&#8216;operational model&#8217; = IETF draft that describes the use case.</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&#8216;large&#8217; = 40K LSAs, 500 IGP nodes.</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
2:44 PM</span></font><o:p></o:p></p>

<div>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><b><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma;font-weight:bold'>Cc:</span></font></b><font face=Tahoma><span
style='font-family:Tahoma'> Alia Atlas; UTTARO, JAMES; <st1:PersonName w:st="on">Shah,
 Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a><o:p></o:p></span></font></p>

<div>

<div>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments<o:p></o:p></span></font></p>

</div>

</div>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>please define
'operational model' ( and 'large' :) . &nbsp;<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 30,
2012 at 1:40 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Hi,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I believe that&#8217;s
10% of what overall work that router does today w.r.t routing. I would like to
see an operational model how such centralized SPF can </span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>provide end-to-end convergence of large number of flows
efficiently. </span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Thanks,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Pranjal</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Alia Atlas<br>
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal); UTTARO, JAMES; <st1:PersonName w:st="on">Shah,
 Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a></span></font><o:p></o:p></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face=Tahoma><span style='font-size:12.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>Alia;<o:p></o:p></span></font></p>

<div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>If there is&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>a) a mechanism for
installing routes, pbr or otherwise, which recurse to directly connected
nexthops<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>b) a mechanism for
gathering topological information<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>then you've
inherently enabled centralized spf.&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 16,
2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]"
target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>I haven't seen a
good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location. &nbsp;Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don't see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><br>
On Thu, Aug 16, 2012 at 12:14 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn't get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It's almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue
is less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<o:p></o:p></span></font></p>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>---snip---<o:p></o:p></span></font></p>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></span></font></p>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

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

</body>

</html>

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C89FINBANSXCHMBSA_--

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 16:12:29 -0700
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--e89a8f234c3f145d0d04c883d208
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01

On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal) <
[email-masked]> wrote:

> **
>
> ‘operational model’ = IETF draft that describes the use case.****
>
> ‘large’ = 40K LSAs, 500 IGP nodes.****
>
> ** **
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 2:44 PM
>
> *To:* **Dutta, Pranjal K** (Pranjal)
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; **
> [email-masked]
> **
> *Subject:* Re: [irs-discuss] IRS comments
> ****
>
>  ** **
>
> please define 'operational model' ( and 'large' :) .  ****
>
> On Thu, Aug 30, 2012 at 1:40 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> Hi,****
>
>          I believe that’s 10% of what overall work that router does today
> w.r.t routing. I would like to see an operational model how such
> centralized SPF can ****
>
> provide end-to-end convergence of large number of flows efficiently. ****
>
>  ****
>
> Thanks,****
>
> Pranjal****
>
>  ****
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 11:59 AM
> *To:* Alia Atlas
> *Cc:* **Dutta, Pranjal K** (Pranjal); UTTARO, JAMES; **Shah, Himanshu**;
> [email-masked]****
>
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
>  ****
>
> Alia;****
>
>  ****
>
> If there is ****
>
>  ****
>
> a) a mechanism for installing routes, pbr or otherwise, which recurse to
> directly connected nexthops****
>
> b) a mechanism for gathering topological information****
>
>  ****
>
> then you've inherently enabled centralized spf. ****
>
>  ****
>
> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:****
>
> I haven't seen a good description of what is intended or desired by
> moving the SPF functionality to a centralized location.  Clearly such
> centralization can have a very bad impact on convergence - which is a
> strong motivator for simultaneously computing fast-reroute
> alternatives (with guaranteed coverage ala MRT) and installing both.
>
> I don't see IRS as having a way of "turning off" the SPF computation
> in the IGP; a different lobotomized IGP protocol/process would be
> needed.
>
> Alia****
>
>
> On Thu, Aug 16, 2012 at 12:14 PM, **Dutta, Pranjal K** (Pranjal)
> <[email-masked]> wrote:
> > "LSDB (I saw an email which talks about reducing IGP to link
> >> distribution protocol and running SPF in centralized network
> >> controller)"
> >
> > I have seen discussions in the past on this and in fact I didn't get
> precisely what is meant. If anybody in the list could brief very
> > precisely that would help a lot.
> >
> > Here is my understanding - the routers would do LSA/LSP flooding for
> OSPF/ISIS as it is done today. So routers would build neighboring
> relationship/adjacencies to participate in flooding and each router builds
> its LSDB.
> >
> > Then the IRS "application" would track LSDB changes and pull up the
> "diffs" from each router (thru "controller") whenever there is a change.
> The application would compute SPF on behalf of each router (LSDB). The
> result of the compute would be pushed by application to each Router (thru
> controller) and inject entries into RIB.
> >
> > Is that correct? How different this going to be from PCE?
> >
> > If this is correct then perhaps we would like to ask what are the
> scalability numbers in LSDB we are talking about?
> >
> > The "application" would be running in a high performance server and so
> SPF compute there is not an issue and perhaps it is good way to synchronize
> FIB update (to a certain extent) to avoid u-loops etc.
> >
> > But when we are managing all routers in the purview of the application,
> the computing power in each router is not uniform. To be realistic, I have
> some concerns on how much "real-timeness" we could achieve between
> application and controllers on such proposals, esp. when scaling numbers
> are high. This leads to higher time lag on inconsistency between
> application SPF compute and FIB update. It's almost like the classic "slow
> peering" issues with TCP like protocols - the high performance peer is
> slowed down by low performance peer.
> >
> > Static route interface is good thing because it is a state that persists
> longer.
> >
> > IGPs may be deployed in very dynamic environments where tight coupling
> is desirable between SPF compute and FIB update. In scaled environments the
> issue is less about SPF compute time and is more about synchronizing the
> FIB.
> >
> > Running on-demand CSPF by IRS application may be fine because of
> persistency of RSVP-TE tunnels in dynamic environments.
> >
> > I apologize if I misunderstood the intent.
> >
> > Thanks,
> > Pranjal****
>
> ---snip---****
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
>  ****
>
> ** **
>

--e89a8f234c3f145d0d04c883d208
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<a href="http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01">http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01</a><br><br><div class="gmail_quote">On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal) <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">

<u></u>

<div lang="EN-US" link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">‘operational model’ = IETF draft that
describes the use case.<u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">‘large’ = 40K LSAs, 500 IGP nodes.<u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe
[mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
2:44 PM</span></font></p><div class="im"><font face="Tahoma"><br>
<b><span style="font-weight:bold">To:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal)<br>
</font></div><font face="Tahoma"><b><span style="font-weight:bold">Cc:</span></b> Alia Atlas; UTTARO, JAMES; <u></u>Shah, Himanshu<u></u>; <u></u><a href="mailto:[email-masked]" target="_blank">[email-masked]</a><div>

<div class="h5"><u></u><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</div></div></font><u></u><u></u><p></p>

</div><div><div class="h5">

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">please define
&#39;operational model&#39; ( and &#39;large&#39; :) .  <u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 30, 2012 at 1:40 PM, <u></u>Dutta,
 Pranjal K<u></u> (Pranjal) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<u></u><u></u></span></font></p>

<div link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Hi,</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">         I believe that’s
10% of what overall work that router does today w.r.t routing. I would like to
see an operational model how such centralized SPF can </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">provide end-to-end convergence of large number of flows
efficiently. </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Thanks,</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Pranjal</span></font><u></u><u></u></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"> </span></font><u></u><u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style="font-weight:bold">To:</span></b> Alia Atlas<br>
<b><span style="font-weight:bold">Cc:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal); UTTARO, JAMES; <u></u>Shah,
 Himanshu<u></u>; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></font><u></u><u></u></p>

<div>

<p class="MsoNormal"><font size="3" face="Tahoma"><span style="font-size:12.0pt;font-family:Tahoma"><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><u></u><u></u></p>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">Alia;<u></u><u></u></span></font></p>

<div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">If there is <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">a) a mechanism for
installing routes, pbr or otherwise, which recurse to directly connected
nexthops<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">b) a mechanism for
gathering topological information<u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">then you&#39;ve
inherently enabled centralized spf. <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 16,
2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">I haven&#39;t seen a
good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location.  Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don&#39;t see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><br>
On Thu, Aug 16, 2012 at 12:14 PM, <u></u>Dutta, Pranjal K<u></u>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn&#39;t get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It&#39;s almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue
is less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<u></u><u></u></span></font></p>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">---snip---<u></u><u></u></span></font></p>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><u></u><u></u></span></font></p>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"> <u></u><u></u></span></font></p>

</div>

</div>

</div>

</div>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div></div></div>

</div>

</blockquote></div><br>

--e89a8f234c3f145d0d04c883d208--

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Edward Crabbe <[email-masked]>
Date: Fri, 31 Aug 2012 04:39:55 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah,  Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

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

'operational model' = IETF draft that describes the use case.
'large' = 40K LSAs, 500 IGP nodes.

________________________________
From: Edward Crabbe [mailto:[email-masked]]
Sent: Thursday, August 30, 2012 2:44 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; UTTARO, JAMES; Shah, Himanshu; [email-masked]
Subject: Re: [irs-discuss] IRS comments

please define 'operational model' ( and 'large' :) .
On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
         I believe that's 10% of what overall work that router does today w.r.t routing. I would like to see an operational model how such centralized SPF can
provide end-to-end convergence of large number of flows efficiently.

Thanks,
Pranjal

________________________________
From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, August 30, 2012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

Alia;

If there is

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops
b) a mechanism for gathering topological information

then you've inherently enabled centralized spf.

On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
I haven't seen a good description of what is intended or desired by
moving the SPF functionality to a centralized location.  Clearly such
centralization can have a very bad impact on convergence - which is a
strong motivator for simultaneously computing fast-reroute
alternatives (with guaranteed coverage ala MRT) and installing both.

I don't see IRS as having a way of "turning off" the SPF computation
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia

On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]<mailto:[email-masked]>> wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
>
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>
> If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.
>
> But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persists longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.
>
> Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.
>
> I apologize if I misunderstood the intent.
>
> Thanks,
> Pranjal
---snip---
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C89BINBANSXCHMBSA_
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="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8216;operational model&#8217; = IETF draft that
describes the use case.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&#8216;large&#8217; = 40K LSAs, 500 IGP nodes.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</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=3 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'> Edward Crabbe
[mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
2:44 PM<br>
<b><span style='font-weight:bold'>To:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal)<br>
<b><span style='font-weight:bold'>Cc:</span></b> Alia Atlas; UTTARO, JAMES; <st1:PersonName
w:st="on">Shah, Himanshu</st1:PersonName>; <st1:PersonName w:st="on">[email-masked]</st1:PersonName><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</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>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>please define
'operational model' ( and 'large' :) . &nbsp;<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Aug 30, 2012 at 1:40 PM, <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal) &lt;<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<div link=blue vlink=blue>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Hi,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I believe that&#8217;s
10% of what overall work that router does today w.r.t routing. I would like to
see an operational model how such centralized SPF can </span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>provide end-to-end convergence of large number of flows
efficiently. </span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Thanks,</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Pranjal</span></font><o:p></o:p></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>&nbsp;</span></font><o:p></o:p></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=3 width="100%" align=center>

</span></font></div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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'> Edward Crabbe [mailto:<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Alia Atlas<br>
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal); UTTARO, JAMES; <st1:PersonName w:st="on">Shah,
 Himanshu</st1:PersonName>; <a href="mailto:[email-masked]"
target="_blank">[email-masked]</a></span></font><o:p></o:p></p>

<div>

<p class=MsoNormal><font size=3 face=Tahoma><span style='font-size:12.0pt;
font-family:Tahoma'><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</span></font><o:p></o:p></p>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>Alia;<o:p></o:p></span></font></p>

<div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>If there is&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>a) a mechanism for
installing routes, pbr or otherwise, which recurse to directly connected
nexthops<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>b) a mechanism for
gathering topological information<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>then you've
inherently enabled centralized spf.&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>On Thu, Aug 16,
2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]"
target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>I haven't seen a
good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location. &nbsp;Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don't see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><br>
On Thu, Aug 16, 2012 at 12:14 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn't get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It's almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue
is less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<o:p></o:p></span></font></p>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>---snip---<o:p></o:p></span></font></p>

<div>

<div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></span></font></p>

</div>

</div>

</div>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;<o:p></o:p></span></font></p>

</div>

</div>

</div>

</div>

</div>

</div>

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

</body>

</html>

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C89BINBANSXCHMBSA_--

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 14:44:02 -0700
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--14dae9340f374328f004c8829526
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

please define 'operational model' ( and 'large' :) .

On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <
[email-masked]> wrote:

> **
>
> Hi,****
>
>          I believe that’s 10% of what overall work that router does today
> w.r.t routing. I would like to see an operational model how such
> centralized SPF can ****
>
> provide end-to-end convergence of large number of flows efficiently. ****
>
> ** **
>
> Thanks,****
>
> Pranjal****
>
> ** **
>  ------------------------------
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Thursday, August 30, 2012 11:59 AM
> *To:* Alia Atlas
> *Cc:* **Dutta, Pranjal K** (Pranjal); UTTARO, JAMES; **Shah, Himanshu**; *
> [email-masked]
> **
> *Subject:* Re: [irs-discuss] IRS comments
> ****
>
>  ** **
>
> Alia;****
>
> ** **
>
> If there is ****
>
> ** **
>
> a) a mechanism for installing routes, pbr or otherwise, which recurse to
> directly connected nexthops****
>
> b) a mechanism for gathering topological information****
>
> ** **
>
> then you've inherently enabled centralized spf. ****
>
> ** **
>
> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:****
>
> I haven't seen a good description of what is intended or desired by
> moving the SPF functionality to a centralized location.  Clearly such
> centralization can have a very bad impact on convergence - which is a
> strong motivator for simultaneously computing fast-reroute
> alternatives (with guaranteed coverage ala MRT) and installing both.
>
> I don't see IRS as having a way of "turning off" the SPF computation
> in the IGP; a different lobotomized IGP protocol/process would be
> needed.
>
> Alia****
>
>
> On Thu, Aug 16, 2012 at 12:14 PM, **Dutta, Pranjal K** (Pranjal)
> <[email-masked]> wrote:
> > "LSDB (I saw an email which talks about reducing IGP to link
> >> distribution protocol and running SPF in centralized network
> >> controller)"
> >
> > I have seen discussions in the past on this and in fact I didn't get
> precisely what is meant. If anybody in the list could brief very
> > precisely that would help a lot.
> >
> > Here is my understanding - the routers would do LSA/LSP flooding for
> OSPF/ISIS as it is done today. So routers would build neighboring
> relationship/adjacencies to participate in flooding and each router builds
> its LSDB.
> >
> > Then the IRS "application" would track LSDB changes and pull up the
> "diffs" from each router (thru "controller") whenever there is a change.
> The application would compute SPF on behalf of each router (LSDB). The
> result of the compute would be pushed by application to each Router (thru
> controller) and inject entries into RIB.
> >
> > Is that correct? How different this going to be from PCE?
> >
> > If this is correct then perhaps we would like to ask what are the
> scalability numbers in LSDB we are talking about?
> >
> > The "application" would be running in a high performance server and so
> SPF compute there is not an issue and perhaps it is good way to synchronize
> FIB update (to a certain extent) to avoid u-loops etc.
> >
> > But when we are managing all routers in the purview of the application,
> the computing power in each router is not uniform. To be realistic, I have
> some concerns on how much "real-timeness" we could achieve between
> application and controllers on such proposals, esp. when scaling numbers
> are high. This leads to higher time lag on inconsistency between
> application SPF compute and FIB update. It's almost like the classic "slow
> peering" issues with TCP like protocols - the high performance peer is
> slowed down by low performance peer.
> >
> > Static route interface is good thing because it is a state that persists
> longer.
> >
> > IGPs may be deployed in very dynamic environments where tight coupling
> is desirable between SPF compute and FIB update. In scaled environments the
> issue is less about SPF compute time and is more about synchronizing the
> FIB.
> >
> > Running on-demand CSPF by IRS application may be fine because of
> persistency of RSVP-TE tunnels in dynamic environments.
> >
> > I apologize if I misunderstood the intent.
> >
> > Thanks,
> > Pranjal****
>
> ---snip---****
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
> ** **
>

--14dae9340f374328f004c8829526
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

please define &#39;operational model&#39; ( and &#39;large&#39; :) .  <br><br><div class="gmail_quote">On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal) <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">

<u></u>

<div lang="EN-US" link="blue" vlink="blue">

<div>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Hi,<u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">         I believe that’s 10% of
what overall work that router does today w.r.t routing. I would like to see an
operational model how such centralized SPF can <u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">provide end-to-end convergence of large
number of flows efficiently. <u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Thanks,<u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy">Pranjal<u></u><u></u></span></font></p>

<p class="MsoNormal"><font color="navy" face="Arial"><span style="font-size:10.0pt;font-family:Arial;color:navy"><u></u> <u></u></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="3" width="100%" align="center">

</span></font></div>

<p class="MsoNormal"><b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma;font-weight:bold">From:</span></font></b><font face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> Edward Crabbe
[mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>
<b><span style="font-weight:bold">Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style="font-weight:bold">To:</span></b> Alia Atlas<br>
<b><span style="font-weight:bold">Cc:</span></b> <u></u>Dutta,
 Pranjal K<u></u> (Pranjal); UTTARO, JAMES; <u></u>Shah,
 Himanshu<u></u>; <u></u><a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></font></p><div><font face="Tahoma"><u></u><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [irs-discuss] IRS
comments</font></div><u></u><u></u><p></p>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">Alia;<u></u><u></u></span></font></p><div><div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">If there is <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">a) a mechanism for installing routes, pbr or otherwise, which recurse
to directly connected nexthops<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">b) a mechanism for gathering topological information<u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">then you&#39;ve inherently enabled centralized spf. <u></u><u></u></span></font></p>

</div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<u></u><u></u></span></font></p>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">I haven&#39;t seen a good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location.  Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don&#39;t see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<u></u><u></u></span></font></p>

<div>

<p class="MsoNormal" style="margin-bottom:12.0pt"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><br>
On Thu, Aug 16, 2012 at 12:14 PM, <u></u>Dutta, Pranjal K<u></u>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn&#39;t get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It&#39;s almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue
is less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<u></u><u></u></span></font></p>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">---snip---<u></u><u></u></span></font></p>

<div>

<div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><u></u><u></u></span></font></p>

</div>

</div>

</div>

<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:12.0pt"><u></u> <u></u></span></font></p>

</div>

</div>

</div></div></div>

</div>

</blockquote></div><br>

--14dae9340f374328f004c8829526--

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Edward Crabbe <[email-masked]>, Alia Atlas <[email-masked]>
Date: Fri, 31 Aug 2012 02:10:59 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "UTTARO, JAMES" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

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

Hi,
         I believe that's 10% of what overall work that router does today w.r.t routing. I would like to see an operational model how such centralized SPF can
provide end-to-end convergence of large number of flows efficiently.

Thanks,
Pranjal

________________________________
From: Edward Crabbe [mailto:[email-masked]]
Sent: Thursday, August 30, 2012 11:59 AM
To: Alia Atlas
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Shah, Himanshu; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Alia;

If there is

a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops
b) a mechanism for gathering topological information

then you've inherently enabled centralized spf.

On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
I haven't seen a good description of what is intended or desired by
moving the SPF functionality to a centralized location.  Clearly such
centralization can have a very bad impact on convergence - which is a
strong motivator for simultaneously computing fast-reroute
alternatives (with guaranteed coverage ala MRT) and installing both.

I don't see IRS as having a way of "turning off" the SPF computation
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia

On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]<mailto:[email-masked]>> wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
>
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>
> If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.
>
> But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persists longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.
>
> Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.
>
> I apologize if I misunderstood the intent.
>
> Thanks,
> Pranjal
---snip---
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C87FINBANSXCHMBSA_
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="PersonName"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<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";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I believe that&#8217;s 10% of
what overall work that router does today w.r.t routing. I would like to see an
operational model how such centralized SPF can <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>provide end-to-end convergence of large
number of flows efficiently. <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Thanks,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Pranjal<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</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=3 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'> Edward Crabbe
[mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Thursday, August 30, 2012
11:59 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Alia Atlas<br>
<b><span style='font-weight:bold'>Cc:</span></b> <st1:PersonName w:st="on">Dutta,
 Pranjal K</st1:PersonName> (Pranjal); UTTARO, JAMES; <st1:PersonName w:st="on">Shah,
 Himanshu</st1:PersonName>; <st1:PersonName w:st="on">[email-masked]</st1:PersonName><br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: [irs-discuss] IRS
comments</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>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>Alia;<o:p></o:p></span></font></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>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>If there is&nbsp;<o:p></o:p></span></font></p>

</div>

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

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>a) a mechanism for installing routes, pbr or otherwise, which recurse
to directly connected nexthops<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>b) a mechanism for gathering topological information<o:p></o:p></span></font></p>

</div>

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

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>then you've inherently enabled centralized spf.&nbsp;<o:p></o:p></span></font></p>

</div>

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

<div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas &lt;<a
href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;
wrote:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>I haven't seen a good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location. &nbsp;Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don't see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<o:p></o:p></span></font></p>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'><br>
On Thu, Aug 16, 2012 at 12:14 PM, <st1:PersonName w:st="on">Dutta, Pranjal K</st1:PersonName>
(Pranjal)<br>
&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;
wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn't get
precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for
OSPF/ISIS as it is done today. So routers would build neighboring
relationship/adjacencies to participate in flooding and each router builds its
LSDB.<br>
&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up
the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever
there is a change. The application would compute SPF on behalf of each router
(LSDB). The result of the compute would be pushed by application to each Router
(thru controller) and inject entries into RIB.<br>
&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the
scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server
and so SPF compute there is not an issue and perhaps it is good way to
synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;<br>
&gt; But when we are managing all routers in the purview of the application,
the computing power in each router is not uniform. To be realistic, I have some
concerns on how much &quot;real-timeness&quot; we could achieve between
application and controllers on such proposals, esp. when scaling numbers are
high. This leads to higher time lag on inconsistency between application SPF
compute and FIB update. It's almost like the classic &quot;slow peering&quot;
issues with TCP like protocols - the high performance peer is slowed down by
low performance peer.<br>
&gt;<br>
&gt; Static route interface is good thing because it is a state that persists
longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is
desirable between SPF compute and FIB update. In scaled environments the issue
is less about SPF compute time and is more about synchronizing the FIB.<br>
&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of
persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<o:p></o:p></span></font></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>---snip---<o:p></o:p></span></font></p>

<div>

<div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>_______________________________________________<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><o:p></o:p></span></font></p>

</div>

</div>

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

</div>

</div>

</body>

</html>

--_000_C584046466ED224CA92C1BC3313B963E13F0B8C87FINBANSXCHMBSA_--

Date: Thu, 30 Aug 2012 15:52:15 -0400
From: Alia Atlas <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Not surprised to hear that :-)

The question for IRS is both what is needed to support different
models/architectures for the routing system where parts may be
centralized - and will the data-models to be defined work for those
centralized parts as well.

Alia

On Thu, Aug 30, 2012 at 3:32 PM, Edward Crabbe <[email-masked]> wrote:
> W/r/t liveness monitoring, neighbor discovery etc: yep, of course.   ^_^
> As someone who runs centralized te, I can tell you that in some environments
> / for some deployment types centralized spf works just fine.
>
> On Thu, Aug 30, 2012 at 12:10 PM, Alia Atlas <[email-masked]> wrote:
>>
>> Ed,
>>
>> Sure - it provides the ability for centralized route computation -
>> whether SPF or other.
>> But that isn't all an IGP does - and the topological information may
>> still rely on link-state information from an IGP.   It also doesn't
>> address convergence concerns.
>>
>> I think there is more to be considered than just whether a central box
>> can run an SPF and install the associated routes.
>>
>> Alia
>>
>>
>> On Thu, Aug 30, 2012 at 2:58 PM, Edward Crabbe <[email-masked]> wrote:
>> > Alia;
>> >
>> > If there is
>> >
>> > a) a mechanism for installing routes, pbr or otherwise, which recurse to
>> > directly connected nexthops
>> > b) a mechanism for gathering topological information
>> >
>> > then you've inherently enabled centralized spf.
>> >
>> > On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:
>> >>
>> >> I haven't seen a good description of what is intended or desired by
>> >> moving the SPF functionality to a centralized location.  Clearly such
>> >> centralization can have a very bad impact on convergence - which is a
>> >> strong motivator for simultaneously computing fast-reroute
>> >> alternatives (with guaranteed coverage ala MRT) and installing both.
>> >>
>> >> I don't see IRS as having a way of "turning off" the SPF computation
>> >> in the IGP; a different lobotomized IGP protocol/process would be
>> >> needed.
>> >>
>> >> Alia
>> >>
>> >> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
>> >> <[email-masked]> wrote:
>> >> > "LSDB (I saw an email which talks about reducing IGP to link
>> >> >> distribution protocol and running SPF in centralized network
>> >> >> controller)"
>> >> >
>> >> > I have seen discussions in the past on this and in fact I didn't get
>> >> > precisely what is meant. If anybody in the list could brief very
>> >> > precisely that would help a lot.
>> >> >
>> >> > Here is my understanding - the routers would do LSA/LSP flooding for
>> >> > OSPF/ISIS as it is done today. So routers would build neighboring
>> >> > relationship/adjacencies to participate in flooding and each router
>> >> > builds
>> >> > its LSDB.
>> >> >
>> >> > Then the IRS "application" would track LSDB changes and pull up the
>> >> > "diffs" from each router (thru "controller") whenever there is a
>> >> > change. The
>> >> > application would compute SPF on behalf of each router (LSDB). The
>> >> > result of
>> >> > the compute would be pushed by application to each Router (thru
>> >> > controller)
>> >> > and inject entries into RIB.
>> >> >
>> >> > Is that correct? How different this going to be from PCE?
>> >> >
>> >> > If this is correct then perhaps we would like to ask what are the
>> >> > scalability numbers in LSDB we are talking about?
>> >> >
>> >> > The "application" would be running in a high performance server and
>> >> > so
>> >> > SPF compute there is not an issue and perhaps it is good way to
>> >> > synchronize
>> >> > FIB update (to a certain extent) to avoid u-loops etc.
>> >> >
>> >> > But when we are managing all routers in the purview of the
>> >> > application,
>> >> > the computing power in each router is not uniform. To be realistic, I
>> >> > have
>> >> > some concerns on how much "real-timeness" we could achieve between
>> >> > application and controllers on such proposals, esp. when scaling
>> >> > numbers are
>> >> > high. This leads to higher time lag on inconsistency between
>> >> > application SPF
>> >> > compute and FIB update. It's almost like the classic "slow peering"
>> >> > issues
>> >> > with TCP like protocols - the high performance peer is slowed down by
>> >> > low
>> >> > performance peer.
>> >> >
>> >> > Static route interface is good thing because it is a state that
>> >> > persists
>> >> > longer.
>> >> >
>> >> > IGPs may be deployed in very dynamic environments where tight
>> >> > coupling
>> >> > is desirable between SPF compute and FIB update. In scaled
>> >> > environments the
>> >> > issue is less about SPF compute time and is more about synchronizing
>> >> > the
>> >> > FIB.
>> >> >
>> >> > Running on-demand CSPF by IRS application may be fine because of
>> >> > persistency of RSVP-TE tunnels in dynamic environments.
>> >> >
>> >> > I apologize if I misunderstood the intent.
>> >> >
>> >> > Thanks,
>> >> > Pranjal
>> >>
>> >> ---snip---
>> >> _______________________________________________
>> >> irs-discuss mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>> >
>> >
>
>

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 12:32:20 -0700
To: Alia Atlas <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--14dae9340f3751084a04c880beba
Content-Type: text/plain; charset=ISO-8859-1

W/r/t liveness monitoring, neighbor discovery etc: yep, of course.   ^_^
As someone who runs centralized te, I can tell you that in some
environments / for some deployment types centralized spf works just fine.

On Thu, Aug 30, 2012 at 12:10 PM, Alia Atlas <[email-masked]> wrote:

> Ed,
>
> Sure - it provides the ability for centralized route computation -
> whether SPF or other.
> But that isn't all an IGP does - and the topological information may
> still rely on link-state information from an IGP.   It also doesn't
> address convergence concerns.
>
> I think there is more to be considered than just whether a central box
> can run an SPF and install the associated routes.
>
> Alia
>
>
> On Thu, Aug 30, 2012 at 2:58 PM, Edward Crabbe <[email-masked]> wrote:
> > Alia;
> >
> > If there is
> >
> > a) a mechanism for installing routes, pbr or otherwise, which recurse to
> > directly connected nexthops
> > b) a mechanism for gathering topological information
> >
> > then you've inherently enabled centralized spf.
> >
> > On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:
> >>
> >> I haven't seen a good description of what is intended or desired by
> >> moving the SPF functionality to a centralized location.  Clearly such
> >> centralization can have a very bad impact on convergence - which is a
> >> strong motivator for simultaneously computing fast-reroute
> >> alternatives (with guaranteed coverage ala MRT) and installing both.
> >>
> >> I don't see IRS as having a way of "turning off" the SPF computation
> >> in the IGP; a different lobotomized IGP protocol/process would be
> >> needed.
> >>
> >> Alia
> >>
> >> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
> >> <[email-masked]> wrote:
> >> > "LSDB (I saw an email which talks about reducing IGP to link
> >> >> distribution protocol and running SPF in centralized network
> >> >> controller)"
> >> >
> >> > I have seen discussions in the past on this and in fact I didn't get
> >> > precisely what is meant. If anybody in the list could brief very
> >> > precisely that would help a lot.
> >> >
> >> > Here is my understanding - the routers would do LSA/LSP flooding for
> >> > OSPF/ISIS as it is done today. So routers would build neighboring
> >> > relationship/adjacencies to participate in flooding and each router
> builds
> >> > its LSDB.
> >> >
> >> > Then the IRS "application" would track LSDB changes and pull up the
> >> > "diffs" from each router (thru "controller") whenever there is a
> change. The
> >> > application would compute SPF on behalf of each router (LSDB). The
> result of
> >> > the compute would be pushed by application to each Router (thru
> controller)
> >> > and inject entries into RIB.
> >> >
> >> > Is that correct? How different this going to be from PCE?
> >> >
> >> > If this is correct then perhaps we would like to ask what are the
> >> > scalability numbers in LSDB we are talking about?
> >> >
> >> > The "application" would be running in a high performance server and so
> >> > SPF compute there is not an issue and perhaps it is good way to
> synchronize
> >> > FIB update (to a certain extent) to avoid u-loops etc.
> >> >
> >> > But when we are managing all routers in the purview of the
> application,
> >> > the computing power in each router is not uniform. To be realistic, I
> have
> >> > some concerns on how much "real-timeness" we could achieve between
> >> > application and controllers on such proposals, esp. when scaling
> numbers are
> >> > high. This leads to higher time lag on inconsistency between
> application SPF
> >> > compute and FIB update. It's almost like the classic "slow peering"
> issues
> >> > with TCP like protocols - the high performance peer is slowed down by
> low
> >> > performance peer.
> >> >
> >> > Static route interface is good thing because it is a state that
> persists
> >> > longer.
> >> >
> >> > IGPs may be deployed in very dynamic environments where tight coupling
> >> > is desirable between SPF compute and FIB update. In scaled
> environments the
> >> > issue is less about SPF compute time and is more about synchronizing
> the
> >> > FIB.
> >> >
> >> > Running on-demand CSPF by IRS application may be fine because of
> >> > persistency of RSVP-TE tunnels in dynamic environments.
> >> >
> >> > I apologize if I misunderstood the intent.
> >> >
> >> > Thanks,
> >> > Pranjal
> >>
> >> ---snip---
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> >
> >
>

--14dae9340f3751084a04c880beba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

W/r/t liveness monitoring, neighbor discovery etc: yep, of course.   ^_^  <div>As someone who runs centralized te, I can tell you that in some environments / for some deployment types centralized spf works just fine.    <div>

<div><br></div><div><div class="gmail_quote">On Thu, Aug 30, 2012 at 12:10 PM, Alia Atlas <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">

Ed,<br>
<br>
Sure - it provides the ability for centralized route computation -<br>
whether SPF or other.<br>
But that isn&#39;t all an IGP does - and the topological information may<br>
still rely on link-state information from an IGP.   It also doesn&#39;t<br>
address convergence concerns.<br>
<br>
I think there is more to be considered than just whether a central box<br>
can run an SPF and install the associated routes.<br>
<span class="HOEnZb"><font color="#888888"><br>
Alia<br>
</font></span><div class="im HOEnZb"><br>
<br>
On Thu, Aug 30, 2012 at 2:58 PM, Edward Crabbe &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
</div><div class="HOEnZb"><div class="h5">&gt; Alia;<br>
&gt;<br>
&gt; If there is<br>
&gt;<br>
&gt; a) a mechanism for installing routes, pbr or otherwise, which recurse to<br>
&gt; directly connected nexthops<br>
&gt; b) a mechanism for gathering topological information<br>
&gt;<br>
&gt; then you&#39;ve inherently enabled centralized spf.<br>
&gt;<br>
&gt; On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; I haven&#39;t seen a good description of what is intended or desired by<br>
&gt;&gt; moving the SPF functionality to a centralized location.  Clearly such<br>
&gt;&gt; centralization can have a very bad impact on convergence - which is a<br>
&gt;&gt; strong motivator for simultaneously computing fast-reroute<br>
&gt;&gt; alternatives (with guaranteed coverage ala MRT) and installing both.<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
&gt;&gt; in the IGP; a different lobotomized IGP protocol/process would be<br>
&gt;&gt; needed.<br>
&gt;&gt;<br>
&gt;&gt; Alia<br>
&gt;&gt;<br>
&gt;&gt; On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)<br>
&gt;&gt; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt; &gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; &gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; &gt;&gt; controller)&quot;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I have seen discussions in the past on this and in fact I didn&#39;t get<br>
&gt;&gt; &gt; precisely what is meant. If anybody in the list could brief very<br>
&gt;&gt; &gt; precisely that would help a lot.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Here is my understanding - the routers would do LSA/LSP flooding for<br>
&gt;&gt; &gt; OSPF/ISIS as it is done today. So routers would build neighboring<br>
&gt;&gt; &gt; relationship/adjacencies to participate in flooding and each router builds<br>
&gt;&gt; &gt; its LSDB.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up the<br>
&gt;&gt; &gt; &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever there is a change. The<br>
&gt;&gt; &gt; application would compute SPF on behalf of each router (LSDB). The result of<br>
&gt;&gt; &gt; the compute would be pushed by application to each Router (thru controller)<br>
&gt;&gt; &gt; and inject entries into RIB.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Is that correct? How different this going to be from PCE?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If this is correct then perhaps we would like to ask what are the<br>
&gt;&gt; &gt; scalability numbers in LSDB we are talking about?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The &quot;application&quot; would be running in a high performance server and so<br>
&gt;&gt; &gt; SPF compute there is not an issue and perhaps it is good way to synchronize<br>
&gt;&gt; &gt; FIB update (to a certain extent) to avoid u-loops etc.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; But when we are managing all routers in the purview of the application,<br>
&gt;&gt; &gt; the computing power in each router is not uniform. To be realistic, I have<br>
&gt;&gt; &gt; some concerns on how much &quot;real-timeness&quot; we could achieve between<br>
&gt;&gt; &gt; application and controllers on such proposals, esp. when scaling numbers are<br>
&gt;&gt; &gt; high. This leads to higher time lag on inconsistency between application SPF<br>
&gt;&gt; &gt; compute and FIB update. It&#39;s almost like the classic &quot;slow peering&quot; issues<br>
&gt;&gt; &gt; with TCP like protocols - the high performance peer is slowed down by low<br>
&gt;&gt; &gt; performance peer.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Static route interface is good thing because it is a state that persists<br>
&gt;&gt; &gt; longer.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; IGPs may be deployed in very dynamic environments where tight coupling<br>
&gt;&gt; &gt; is desirable between SPF compute and FIB update. In scaled environments the<br>
&gt;&gt; &gt; issue is less about SPF compute time and is more about synchronizing the<br>
&gt;&gt; &gt; FIB.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Running on-demand CSPF by IRS application may be fine because of<br>
&gt;&gt; &gt; persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I apologize if I misunderstood the intent.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Thanks,<br>
&gt;&gt; &gt; Pranjal<br>
&gt;&gt;<br>
&gt;&gt; ---snip---<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; irs-discuss mailing list<br>
&gt;&gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>
&gt;<br>
&gt;<br>
</div></div></blockquote></div><br></div></div></div>

--14dae9340f3751084a04c880beba--

Date: Thu, 30 Aug 2012 15:10:31 -0400
From: Alia Atlas <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Ed,

Sure - it provides the ability for centralized route computation -
whether SPF or other.
But that isn't all an IGP does - and the topological information may
still rely on link-state information from an IGP.   It also doesn't
address convergence concerns.

I think there is more to be considered than just whether a central box
can run an SPF and install the associated routes.

Alia

On Thu, Aug 30, 2012 at 2:58 PM, Edward Crabbe <[email-masked]> wrote:
> Alia;
>
> If there is
>
> a) a mechanism for installing routes, pbr or otherwise, which recurse to
> directly connected nexthops
> b) a mechanism for gathering topological information
>
> then you've inherently enabled centralized spf.
>
> On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:
>>
>> I haven't seen a good description of what is intended or desired by
>> moving the SPF functionality to a centralized location.  Clearly such
>> centralization can have a very bad impact on convergence - which is a
>> strong motivator for simultaneously computing fast-reroute
>> alternatives (with guaranteed coverage ala MRT) and installing both.
>>
>> I don't see IRS as having a way of "turning off" the SPF computation
>> in the IGP; a different lobotomized IGP protocol/process would be
>> needed.
>>
>> Alia
>>
>> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>> > "LSDB (I saw an email which talks about reducing IGP to link
>> >> distribution protocol and running SPF in centralized network
>> >> controller)"
>> >
>> > I have seen discussions in the past on this and in fact I didn't get
>> > precisely what is meant. If anybody in the list could brief very
>> > precisely that would help a lot.
>> >
>> > Here is my understanding - the routers would do LSA/LSP flooding for
>> > OSPF/ISIS as it is done today. So routers would build neighboring
>> > relationship/adjacencies to participate in flooding and each router builds
>> > its LSDB.
>> >
>> > Then the IRS "application" would track LSDB changes and pull up the
>> > "diffs" from each router (thru "controller") whenever there is a change. The
>> > application would compute SPF on behalf of each router (LSDB). The result of
>> > the compute would be pushed by application to each Router (thru controller)
>> > and inject entries into RIB.
>> >
>> > Is that correct? How different this going to be from PCE?
>> >
>> > If this is correct then perhaps we would like to ask what are the
>> > scalability numbers in LSDB we are talking about?
>> >
>> > The "application" would be running in a high performance server and so
>> > SPF compute there is not an issue and perhaps it is good way to synchronize
>> > FIB update (to a certain extent) to avoid u-loops etc.
>> >
>> > But when we are managing all routers in the purview of the application,
>> > the computing power in each router is not uniform. To be realistic, I have
>> > some concerns on how much "real-timeness" we could achieve between
>> > application and controllers on such proposals, esp. when scaling numbers are
>> > high. This leads to higher time lag on inconsistency between application SPF
>> > compute and FIB update. It's almost like the classic "slow peering" issues
>> > with TCP like protocols - the high performance peer is slowed down by low
>> > performance peer.
>> >
>> > Static route interface is good thing because it is a state that persists
>> > longer.
>> >
>> > IGPs may be deployed in very dynamic environments where tight coupling
>> > is desirable between SPF compute and FIB update. In scaled environments the
>> > issue is less about SPF compute time and is more about synchronizing the
>> > FIB.
>> >
>> > Running on-demand CSPF by IRS application may be fine because of
>> > persistency of RSVP-TE tunnels in dynamic environments.
>> >
>> > I apologize if I misunderstood the intent.
>> >
>> > Thanks,
>> > Pranjal
>>
>> ---snip---
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 11:58:54 -0700
To: Alia Atlas <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--f46d04462d6cbcc14604c88046b0
Content-Type: text/plain; charset=ISO-8859-1

Alia;

If there is

a) a mechanism for installing routes, pbr or otherwise, which recurse to
directly connected nexthops
b) a mechanism for gathering topological information

then you've inherently enabled centralized spf.

On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <[email-masked]> wrote:

> I haven't seen a good description of what is intended or desired by
> moving the SPF functionality to a centralized location.  Clearly such
> centralization can have a very bad impact on convergence - which is a
> strong motivator for simultaneously computing fast-reroute
> alternatives (with guaranteed coverage ala MRT) and installing both.
>
> I don't see IRS as having a way of "turning off" the SPF computation
> in the IGP; a different lobotomized IGP protocol/process would be
> needed.
>
> Alia
>
> On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
> <[email-masked]> wrote:
> > "LSDB (I saw an email which talks about reducing IGP to link
> >> distribution protocol and running SPF in centralized network
> >> controller)"
> >
> > I have seen discussions in the past on this and in fact I didn't get
> precisely what is meant. If anybody in the list could brief very
> > precisely that would help a lot.
> >
> > Here is my understanding - the routers would do LSA/LSP flooding for
> OSPF/ISIS as it is done today. So routers would build neighboring
> relationship/adjacencies to participate in flooding and each router builds
> its LSDB.
> >
> > Then the IRS "application" would track LSDB changes and pull up the
> "diffs" from each router (thru "controller") whenever there is a change.
> The application would compute SPF on behalf of each router (LSDB). The
> result of the compute would be pushed by application to each Router (thru
> controller) and inject entries into RIB.
> >
> > Is that correct? How different this going to be from PCE?
> >
> > If this is correct then perhaps we would like to ask what are the
> scalability numbers in LSDB we are talking about?
> >
> > The "application" would be running in a high performance server and so
> SPF compute there is not an issue and perhaps it is good way to synchronize
> FIB update (to a certain extent) to avoid u-loops etc.
> >
> > But when we are managing all routers in the purview of the application,
> the computing power in each router is not uniform. To be realistic, I have
> some concerns on how much "real-timeness" we could achieve between
> application and controllers on such proposals, esp. when scaling numbers
> are high. This leads to higher time lag on inconsistency between
> application SPF compute and FIB update. It's almost like the classic "slow
> peering" issues with TCP like protocols - the high performance peer is
> slowed down by low performance peer.
> >
> > Static route interface is good thing because it is a state that persists
> longer.
> >
> > IGPs may be deployed in very dynamic environments where tight coupling
> is desirable between SPF compute and FIB update. In scaled environments the
> issue is less about SPF compute time and is more about synchronizing the
> FIB.
> >
> > Running on-demand CSPF by IRS application may be fine because of
> persistency of RSVP-TE tunnels in dynamic environments.
> >
> > I apologize if I misunderstood the intent.
> >
> > Thanks,
> > Pranjal
>
> ---snip---
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

--f46d04462d6cbcc14604c88046b0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Alia;<div><br></div><div>If there is </div><div><br></div><div>a) a mechanism for installing routes, pbr or otherwise, which recurse to directly connected nexthops<br><div>b) a mechanism for gathering topological information</div>

<div><br></div><div>then you&#39;ve inherently enabled centralized spf. </div><div><br></div><div><div class="gmail_quote">On Thu, Aug 16, 2012 at 9:34 AM, Alia Atlas <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">I haven&#39;t seen a good description of what is intended or desired by<br>
moving the SPF functionality to a centralized location.  Clearly such<br>
centralization can have a very bad impact on convergence - which is a<br>
strong motivator for simultaneously computing fast-reroute<br>
alternatives (with guaranteed coverage ala MRT) and installing both.<br>
<br>
I don&#39;t see IRS as having a way of &quot;turning off&quot; the SPF computation<br>
in the IGP; a different lobotomized IGP protocol/process would be<br>
needed.<br>
<br>
Alia<br>
<div class="im"><br>
On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)<br>
&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; &quot;LSDB (I saw an email which talks about reducing IGP to link<br>
&gt;&gt; distribution protocol and running SPF in centralized network<br>
&gt;&gt; controller)&quot;<br>
&gt;<br>
&gt; I have seen discussions in the past on this and in fact I didn&#39;t get precisely what is meant. If anybody in the list could brief very<br>
&gt; precisely that would help a lot.<br>
&gt;<br>
&gt; Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.<br>

&gt;<br>
&gt; Then the IRS &quot;application&quot; would track LSDB changes and pull up the &quot;diffs&quot; from each router (thru &quot;controller&quot;) whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.<br>

&gt;<br>
&gt; Is that correct? How different this going to be from PCE?<br>
&gt;<br>
&gt; If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?<br>
&gt;<br>
&gt; The &quot;application&quot; would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.<br>

&gt;<br>
&gt; But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much &quot;real-timeness&quot; we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It&#39;s almost like the classic &quot;slow peering&quot; issues with TCP like protocols - the high performance peer is slowed down by low performance peer.<br>

&gt;<br>
&gt; Static route interface is good thing because it is a state that persists longer.<br>
&gt;<br>
&gt; IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.<br>

&gt;<br>
&gt; Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.<br>
&gt;<br>
&gt; I apologize if I misunderstood the intent.<br>
&gt;<br>
&gt; Thanks,<br>
&gt; Pranjal<br>
<br>
</div>---snip---<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br></div></div>

--f46d04462d6cbcc14604c88046b0--

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 30 Aug 2012 01:16:45 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

I am not quite sure about this. We find the problem statement of IRS as follows:

<>
   In order to enable applications to have access to and control over
   information in the Internet's routing system, we need a publically
   documented interface specification.  The interface needs to support
   real-time, transaction-based interactions using efficient data models
   and encodings.  Furthermore, the interface must support a variety of
   use cases including those where verified control feed-back loops are
   needed. </>

The way I understand, it's about building flexible/programmable 
abstractions into Routing Systems - It's not necessary that entire control plane is taken away. So I don't see the framework as complete separation 
of control plane and data plane.

The IRS frame work further highlights Bidirectional Interfaces to the Routing System.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephane Bortzmeyer
Sent: Friday, August 24, 2012 9:06 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

On Thu, Jul 26, 2012 at 05:45:29PM -0700,
 IETF Secretariat <[email-masked]> wrote 
 a message of 34 lines which said:

> A new IETF non-working group email list has been created.
> 
> List address: [email-masked]
> Archive: http://www.ietf.org/mail-archive/web/irs-discuss/
> To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss

It really looks like very close from what the Forces working group
have been doing. Can anyone explain why we need to start a new
project?
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 27 Aug 2012 08:39:28 -0400
To: Susan Hares <[email-masked]>
Cc: Benson Schliesser <[email-masked]>, [email-masked], Susan Hares <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

Hi Sue,

On Mon, Aug 27, 2012 at 8:00 AM, Susan Hares <[email-masked]> wrote:
> Jamal:
>
> Can you give an example of how IRS and Forces might interact via this route
> socket?
> Due to the wide background on the lists (irs & forces) , it would be good to
> give an example within a switch or router as context.

Just the example i posted from the RFC which demonstrates access to a FIB
and nexthop tables. All of that can be delivered with ForCES (given netlink
was an input in ForCES design).
The semantics to a RIB as opposed to a FIB are different.  Example, the
credentials are weaker on the FIB aspects (the "protocol" field in the
route message). But all that is a model issue i.e ForCES is agnostic
of the description.

I know you are a guru in this area - so hoping to get some wisdom.
Sorry for dragging this discussion into this direction.

cheers,
jamal

From: "Susan Hares" <[email-masked]>
To: "'Jamal Hadi Salim'" <[email-masked]>, "'Susan Hares'" <[email-masked]>
Date: Mon, 27 Aug 2012 08:00:08 -0400
Cc: 'Benson Schliesser' <[email-masked]>, [email-masked], 'Stephane Bortzmeyer' <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

Jamal:

Can you give an example of how IRS and Forces might interact via this route
socket? 
Due to the wide background on the lists (irs & forces) , it would be good to
give an example within a switch or router as context.

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jamal Hadi Salim
Sent: Monday, August 27, 2012 7:42 AM
To: Susan Hares
Cc: Benson Schliesser; [email-masked]; Stephane Bortzmeyer;
[email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss --
Interface to The Internet Routing System (IRS)

With apologies to Alia, I feel obligated to feed this discussion ;->

On Mon, Aug 27, 2012 at 7:22 AM, Susan Hares <[email-masked]> wrote:
> Benson:
>
> Forces is looking between the control plane and the data forwarding plane.
>The IRS work is focused on contacting between a control program and the
routing process on the routing >control plane.
>

In my view:
IRS may provide an API or abstraction that looks like a routing sockets or
netlink_route (refer to section 3.1 and 3.2 of RFC 3549), underneath the
implementation maybe indeed ForCES.

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

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 27 Aug 2012 07:42:28 -0400
To: Susan Hares <[email-masked]>
Cc: Benson Schliesser <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

With apologies to Alia, I feel obligated to feed this discussion ;->

On Mon, Aug 27, 2012 at 7:22 AM, Susan Hares <[email-masked]> wrote:
> Benson:
>
> Forces is looking between the control plane and the data forwarding plane.
>The IRS work is focused on contacting between a control program and the routing process on the routing >control plane.
>

In my view:
IRS may provide an API or abstraction that looks like a routing sockets or
netlink_route (refer to section 3.1 and 3.2 of RFC 3549), underneath
the implementation maybe indeed ForCES.

cheers,
jamal

From: Susan Hares <[email-masked]>
To: Benson Schliesser <[email-masked]>, Stephane Bortzmeyer <[email-masked]>
Date: Mon, 27 Aug 2012 11:22:48 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

Benson:

Forces is looking between the control plane and the data forwarding plane. The IRS work is focused on contacting between a control program and the routing process on the routing control plane.

X central controller 
(IRS Commissioner) 
  | 
 IRS client  (Control Plane (CP) - routing process) 
 [routing processes]
 CP - 
  ----
  Forces CE 
    |
  Forces FE     

Sue Hares 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benson Schliesser
Sent: Friday, August 24, 2012 9:24 AM
To: Stephane Bortzmeyer
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

Hi, Stephane.

On 8/24/12 11:05 AM, Stephane Bortzmeyer wrote:
>> A new IETF non-working group email list has been created.
>>
>> List address: [email-masked]
>> Archive: http://www.ietf.org/mail-archive/web/irs-discuss/
>> To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss
> It really looks like very close from what the Forces working group
> have been doing. Can anyone explain why we need to start a new
> project?

At a high level, I think there is a different assumption about where the 
control-plane resides. In IRS the forwarding and control planes might be 
co-resident in the router (i.e. not "separated"), and the IRS protocol 
would be a way of extending limited control over routing state to 
external applications.

If I understand ForCES correctly (which is possibly not the case) then I 
imagine it could be used in a similar architecture and/or as a protocol 
layer for IRS. But the first step in the context of IRS is to make a 
problem statement, understand requirements, etc.

Others might have more intelligent comments, which I welcome. :) But 
please let me know if this perspective helps clarify things, and/or if 
I'm missing some ideas that I should understand better, etc.

Cheers,
-Benson

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

From: Jamal Hadi Salim <[email-masked]>
Date: Mon, 27 Aug 2012 07:23:25 -0400
To: Benson Schliesser <[email-masked]>
Cc: [email-masked], Stephane Bortzmeyer <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

On Fri, Aug 24, 2012 at 12:24 PM, Benson Schliesser
<[email-masked]> wrote:

> At a high level, I think there is a different assumption about where the
> control-plane resides.

Clarification on the generic statement above below.

>In IRS the forwarding and control planes might be
> co-resident in the router (i.e. not "separated"), and the IRS protocol would
> be a way of extending limited control over routing state to external
> applications.
>
> If I understand ForCES correctly (which is possibly not the case) then I
> imagine it could be used in a similar architecture and/or as a protocol
> layer for IRS. But the first step in the context of IRS is to make a problem
> statement, understand requirements, etc.
>

Indeed. Once clarity sets in on the requirements, ForCES may or may not be a
good choice.

Where i feel obligated to respond is to the comment on your first part.
It boxes ForCES into only being useful in a southbound control-datapath
separation.  We've used it to control a bunch of ethernet switches which have
co-resident  control/data plane from the vendor. We've used it to configure
things that are not packet processing entities - consider this presentation
https://www.ietf.org/proceedings/84/slides/slides-84-forces-2.pdf
which illustrates how we model a configuration file (nothing to do with a
datapath functional block) into an LFB and then proceed to query/set
from the CE.

cheers,
jamal

Date: Sun, 26 Aug 2012 15:18:19 +0200
From: Abdussalam Baryun <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [irs-discuss] draft-ward-irs-framework-00

Hi Alia,

 Reading through to find the definition of IRS within
 <draft-ward-irs-framework-00> I got confused not sure
 its relationship with the network interfaces, please advise,

 Regards
 Abdussalam

Date: Fri, 24 Aug 2012 11:24:12 -0500
From: Benson Schliesser <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [irs-discuss] [forces] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

Hi, Stephane.

On 8/24/12 11:05 AM, Stephane Bortzmeyer wrote:
>> A new IETF non-working group email list has been created.
>>
>> List address: [email-masked]
>> Archive: http://www.ietf.org/mail-archive/web/irs-discuss/
>> To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss
> It really looks like very close from what the Forces working group
> have been doing. Can anyone explain why we need to start a new
> project?

At a high level, I think there is a different assumption about where the 
control-plane resides. In IRS the forwarding and control planes might be 
co-resident in the router (i.e. not "separated"), and the IRS protocol 
would be a way of extending limited control over routing state to 
external applications.

If I understand ForCES correctly (which is possibly not the case) then I 
imagine it could be used in a similar architecture and/or as a protocol 
layer for IRS. But the first step in the context of IRS is to make a 
problem statement, understand requirements, etc.

Others might have more intelligent comments, which I welcome. :) But 
please let me know if this perspective helps clarify things, and/or if 
I'm missing some ideas that I should understand better, etc.

Cheers,
-Benson

Date: Fri, 24 Aug 2012 18:05:40 +0200
From: Stephane Bortzmeyer <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [irs-discuss] New Non-WG Mailing List: irs-discuss -- Interface to The Internet Routing System (IRS)

On Thu, Jul 26, 2012 at 05:45:29PM -0700,
 IETF Secretariat <[email-masked]> wrote 
 a message of 34 lines which said:

> A new IETF non-working group email list has been created.
> 
> List address: [email-masked]
> Archive: http://www.ietf.org/mail-archive/web/irs-discuss/
> To subscribe: https://www.ietf.org/mailman/listinfo/irs-discuss

It really looks like very close from what the Forces working group
have been doing. Can anyone explain why we need to start a new
project?

From: Thomas Nadeau <[email-masked]>
Date: Sat, 18 Aug 2012 07:12:24 -0400
References: <[email-masked]>	<CAG=[email-masked]>	<[email-masked]>	<CAG=[email-masked]>	<CAG4d1rd_p6x_+PsHWtsYU=[email-masked]>	<[email-masked]>	<CAG4d1reWGjUU-z=[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<CACKN6JFMZqOnHU=vEkx8WxwSLjg5MYY=[email-masked]>	<[email-masked] > <B37E6A2CE5957F4E83 [email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]> <000501cd7cad$9073 [email-masked]>
To: "Susan Hares" <[email-masked]>
X-Mailer: Apple Mail (2.1485)
Cc: 'Mach Chen' <[email-masked]>, [email-masked], "'Shah, Himanshu'" <[email-masked]>, 'Alia Atlas' <[email-masked]>, "'UTTARO, JAMES'" <[email-masked]>, "'Dutta, Pranjal K \(Pranjal\)'" <[email-masked]>
Subject: Re: [irs-discuss] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJUlMgY29tbWVudHM=?X-BeenThere: [email-masked]
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/irs-discuss>, <mailto:[email-masked]?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/irs-discuss>
List-Post: <mailto:[email-masked]>
List-Help: <mailto:[email-masked]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/irs-discuss>, <mailto:[email-masked]?subject=subscribe>
X-List-Received-Date: Sat, 18 Aug 2012 11:12:30 -0000

On Aug 17, 2012:3:21 PM, at 3:21 PM, "Susan Hares" <[email-masked]> wrote:

> Tom and Mach: 
> 
> IMHO - both cases are seen in today's internet. 
> 
> +1 to Tom - Current cases such as VPNs (monitoring & interface adding) - is a current case where direct interaction may be nice
> 
> +1 to Mach - Operational cases exist where Applications orchestrate (Applications choose DC with open VM systems) and then talk to the IRS Client who commissions individual node IRS agents to perform tasks.
> 
> IMHO the IRS system is a good tool to get interact with routing system. Unlike the generic SNMP hammer, it may be a Swiss army knife tool with multiple interface methods into the system. 

	That is precisely one of its big (potential) advantages. 

	--Tom

> 
> What do you think?
> Sue  
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
> Sent: Friday, August 17, 2012 10:09 AM
> To: Mach Chen
> Cc: [email-masked]; UTTARO, JAMES; Dutta, Pranjal K (Pranjal); Shah, Himanshu; Alia Atlas
> Subject: Re: [irs-discuss] ç­”å¤: ç­”å¤: IRS comments
> 
> 
> On Aug 16, 2012, at 10:38 PM, Mach Chen <[email-masked]> wrote:
> 
>> Hi Alia,
>> 
>> It's great to define uniform interfaces to the applications, but I am not sure whether the IRS interfaces could be directly used by the applications, in the IRS framework, the applications talk to the IRS agents, IMHO, the IRS agent (it may be the controller or orchestrator role from the SDN point of view, and the IRS interfaces are the southbound interfaces ) should shield the variety of the IRS interfaces.  
> 
> The idea is definitely to allow direct use of the interface of that is operationally desired.
> 
> Tom 
> 
>> And I agree that we should currently focus on the use cases and then define a clear scope. Here is a rough SDN related use case draft (http://tools.ietf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I am not sure this is related to IRS. 
>> 
>> Best regards,
>> Mach
>> 
>>> -----é‚®ä»¶åŽŸä»¶-----
>>> å‘ä»¶äºº: Alia Atlas [mailto:[email-masked]]
>>> å‘é€æ—¶é—´: 2012å¹´8æœˆ17æ—¥ 10:13
>>> æ”¶ä»¶äºº: Mach Chen
>>> æŠ„é€: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K (Pranjal); 
>>> [email-masked]
>>> ä¸»é¢˜: Re: ç­”å¤: [irs-discuss] IRS comments
>>> 
>>> Hi Mach,
>>> 
>>> Right - that is one reason why I'm not sure that a CSPF computation 
>>> piece is needed for the RSVP sub-interface.  On the other side, 
>>> there's benefit to not requiring an application to understand too 
>>> many different protocols.
>>> 
>>> We need to discuss what scope makes sense for the sub-interfaces.  I 
>>> think the use-cases will drive this.
>>> 
>>> Alia
>>> 
>>> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen <[email-masked]>
>>> wrote:
>>>> Hi Alia,
>>>> 
>>>> I am a little confused, the said RSVP sub-interface (on-demand CSPF 
>>>> interface)
>>> seems what exactly PCEP does today. My understanding of IRS is that 
>>> it may be complementary on topology discovery.
>>>> 
>>>> Best regards,
>>>> Mach
>>>> 
>>>>> -----é‚®ä»¶åŽŸä»¶-----
>>>>> å‘ä»¶äºº: [email-masked] 
>>>>> [mailto:[email-masked]]
>>> ä»£
>>>>> è¡¨ Alia Atlas
>>>>> å‘é€æ—¶é—´: 2012å¹´8æœˆ17æ—¥ 9:45
>>>>> æ”¶ä»¶äºº: Shah, Himanshu
>>>>> æŠ„é€: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); [email-masked]
>>>>> ä¸»é¢˜: Re: [irs-discuss] IRS comments
>>>>> 
>>>>> I'm not entirely clear on the model or question you are asking.  An 
>>>>> application could learn topology via IRS to the appropriate IRS 
>>>>> agents, do CSPF computations, and support a signaling/CSPF-like 
>>>>> sub-interface (if we define such for IRS) as an IRS agent.  Another 
>>>>> application could query the first for the CSPF results and then use 
>>>>> IRS to trigger signaling on the appropriate device.
>>>>> 
>>>>> I'm not sure if it makes sense to have an IRS sub-interface that 
>>>>> requests CSPF computation, but it might come as part of an RSVP 
>>>>> sub-interface to trigger signaling.  We'll have to see about 
>>>>> use-cases.
>>>>> 
>>>>> I don't see a strong motivation to duplicate existing work.
>>>>> 
>>>>> Alia
>>>>> 
>>>>> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu <[email-masked]>
>>> wrote:
>>>>>> I was wondering if PCE and IRS could have overlapping functionality.
>>>>>> 
>>>>>> Meaning, can an IRS interface user at both ends (node and 
>>>>>> controller) be a
>>>>> non-PCE entity and perform
>>>>>> the same service as what PCE does?
>>>>>> 
>>>>>> It seems like you are saying that could work co-operatively...
>>>>>> 
>>>>>> Thanks,
>>>>>> himanshu
>>>>> 
>>>>> ==snip===
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 
> 

From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Date: Fri, 17 Aug 2012 15:52:24 -0400
Cc: Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>

This is a multipart message in MIME format.

------=_NextPart_000_0019_01CD7C90.4B8F4DB0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Gert:
 
You've hit on many good points. 
 
a.  +1 - You are right. NM has become a non-specific term. In history, ISO
defined NM as specific features (configuration, fault, performance, and
others). 
b.  +1 - roll-forward/roll-back is what is necessary.  IRS protocol, DB and
policy must allow.
c.  Sorry - I see from your 2nd message that I misunderstood your point. 

Sue
 
--------
Susan,
 
Q1: Which NM are you implying here? 
A: traditionally a functional view on the subject has been used. Think about
it. Does the fact that a piece of Software monitors a device justify to name
it 'Network Management
<http://www.ietf.org/mail-archive/web/irs-discuss/current/msg00151.html> '?
Is CLI a Network Management?
 
Q2: Configuration included download plus transactional (roll
forward/roll-back). 
A: that's what's required to keep two persistent databases aligned.
 
A3: Your description does not match the current status of the IGPs or BGP
implementations. 
Q3: what let you to that conclusion?
Those are CP protocols.
 
Q4: Where do you place the Graceful-Restart
<http://www.ietf.org/mail-archive/web/irs-discuss/current/msg00151.html>  or
Hitless Restart or High availability
<http://www.ietf.org/mail-archive/web/irs-discuss/current/msg00151.html>
work? Do you place this in a PCE or a stateful PCE? 

A4: IETF work is always placed between 2 or more entities because we deal
with protocols.

------=_NextPart_000_0019_01CD7C90.4B8F4DB0
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: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;
	font-family:"Calibri","sans-serif";}
@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:1067729614;
	mso-list-type:hybrid;
	mso-list-template-ids:1247163784 67698713 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
@list l0:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;}
@list l0:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;}
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><pre>Gert:<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>You&#8217;ve hit on many good points. <o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>a.<span style='font:7.0pt "Times New Roman"'>&nbsp; </span></span><![endif]>+1 &#8211; You are right. NM has become a non-specific term. In history, ISO defined NM as specific features (configuration, fault, performance, and others). <o:p></o:p></pre><pre style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>b.<span style='font:7.0pt "Times New Roman"'>&nbsp; </span></span><![endif]>+1 &#8211; roll-forward/roll-back is what is necessary.&nbsp; IRS protocol, DB and policy must allow.<o:p></o:p></pre><pre style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><span style='mso-list:Ignore'>c.<span style='font:7.0pt "Times New Roman"'>&nbsp; </span></span><![endif]>Sorry &#8211; I see from your 2<sup>nd</sup> message that I misunderstood your point. <o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Sue<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>--------<o:p></o:p></pre><pre>Susan,<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Q1: Which NM are you implying here? <o:p></o:p></pre><pre>A: traditionally a functional view on the subject has been used. Think about it. Does the fact that a piece of Software monitors a device justify to name it '<a href="http://www.ietf.org/mail-archive/web/irs-discuss/current/msg00151.html" id="FALINK_2_0_1">Network Management</a>'? Is CLI a Network Management?<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Q2: Configuration included download plus transactional (roll forward/roll-back). <o:p></o:p></pre><pre>A: that's what's required to keep two persistent databases aligned.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>A3: Your description does not match the current status of the IGPs or BGP implementations. <o:p></o:p></pre><pre>Q3: what let you to that conclusion?<o:p></o:p></pre><pre>Those are CP protocols.<o:p></o:p></pre><pre><o:p>&nbsp;</o:p></pre><pre>Q4: Where do you place the Graceful-<a href="http://www.ietf.org/mail-archive/web/irs-discuss/current/msg00151.html" id="FALINK_1_0_0">Restart</a> or Hitless Restart or <a href="http://www.ietf.org/mail-archive/web/irs-discuss/current/msg00151.html" id="FALINK_3_0_2">High availability</a> work? Do you place this in a PCE or a stateful PCE? <o:p></o:p></pre><p class=MsoNormal>A4: IETF work is always placed between 2 or more entities because we deal with protocols.<o:p></o:p></p></div></body></html>
------=_NextPart_000_0019_01CD7C90.4B8F4DB0--

From: "Susan Hares" <[email-masked]>
To: "'Thomas Nadeau'" <[email-masked]>, "'Mach Chen'" <[email-masked]>
Date: Fri, 17 Aug 2012 15:21:55 -0400
Cc: 'Alia Atlas' <[email-masked]>, "'UTTARO, JAMES'" <[email-masked]>, "'Dutta, Pranjal K \(Pranjal\)'" <[email-masked]>, "'Shah, Himanshu'" <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJUlMgY29tbWVudHM=?X-BeenThere: [email-masked]

Tom and Mach: 

IMHO - both cases are seen in today's internet. 

+1 to Tom - Current cases such as VPNs (monitoring & interface adding) - is a current case where direct interaction may be nice

+1 to Mach - Operational cases exist where Applications orchestrate (Applications choose DC with open VM systems) and then talk to the IRS Client who commissions individual node IRS agents to perform tasks.

IMHO the IRS system is a good tool to get interact with routing system. Unlike the generic SNMP hammer, it may be a Swiss army knife tool with multiple interface methods into the system. 

What do you think?
Sue  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Friday, August 17, 2012 10:09 AM
To: Mach Chen
Cc: [email-masked]; UTTARO, JAMES; Dutta, Pranjal K (Pranjal); Shah, Himanshu; Alia Atlas
Subject: Re: [irs-discuss] ç­”å¤: ç­”å¤: IRS comments

On Aug 16, 2012, at 10:38 PM, Mach Chen <[email-masked]> wrote:

> Hi Alia,
> 
> It's great to define uniform interfaces to the applications, but I am not sure whether the IRS interfaces could be directly used by the applications, in the IRS framework, the applications talk to the IRS agents, IMHO, the IRS agent (it may be the controller or orchestrator role from the SDN point of view, and the IRS interfaces are the southbound interfaces ) should shield the variety of the IRS interfaces.  

The idea is definitely to allow direct use of the interface of that is operationally desired.

Tom 

> And I agree that we should currently focus on the use cases and then define a clear scope. Here is a rough SDN related use case draft (http://tools.ietf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I am not sure this is related to IRS. 
> 
> Best regards,
> Mach
> 
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: Alia Atlas [mailto:[email-masked]]
>> å‘é€æ—¶é—´: 2012å¹´8æœˆ17æ—¥ 10:13
>> æ”¶ä»¶äºº: Mach Chen
>> æŠ„é€: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K (Pranjal); 
>> [email-masked]
>> ä¸»é¢˜: Re: ç­”å¤: [irs-discuss] IRS comments
>> 
>> Hi Mach,
>> 
>> Right - that is one reason why I'm not sure that a CSPF computation 
>> piece is needed for the RSVP sub-interface.  On the other side, 
>> there's benefit to not requiring an application to understand too 
>> many different protocols.
>> 
>> We need to discuss what scope makes sense for the sub-interfaces.  I 
>> think the use-cases will drive this.
>> 
>> Alia
>> 
>> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen <[email-masked]>
>> wrote:
>>> Hi Alia,
>>> 
>>> I am a little confused, the said RSVP sub-interface (on-demand CSPF 
>>> interface)
>> seems what exactly PCEP does today. My understanding of IRS is that 
>> it may be complementary on topology discovery.
>>> 
>>> Best regards,
>>> Mach
>>> 
>>>> -----é‚®ä»¶åŽŸä»¶-----
>>>> å‘ä»¶äºº: [email-masked] 
>>>> [mailto:[email-masked]]
>> ä»£
>>>> è¡¨ Alia Atlas
>>>> å‘é€æ—¶é—´: 2012å¹´8æœˆ17æ—¥ 9:45
>>>> æ”¶ä»¶äºº: Shah, Himanshu
>>>> æŠ„é€: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); [email-masked]
>>>> ä¸»é¢˜: Re: [irs-discuss] IRS comments
>>>> 
>>>> I'm not entirely clear on the model or question you are asking.  An 
>>>> application could learn topology via IRS to the appropriate IRS 
>>>> agents, do CSPF computations, and support a signaling/CSPF-like 
>>>> sub-interface (if we define such for IRS) as an IRS agent.  Another 
>>>> application could query the first for the CSPF results and then use 
>>>> IRS to trigger signaling on the appropriate device.
>>>> 
>>>> I'm not sure if it makes sense to have an IRS sub-interface that 
>>>> requests CSPF computation, but it might come as part of an RSVP 
>>>> sub-interface to trigger signaling.  We'll have to see about 
>>>> use-cases.
>>>> 
>>>> I don't see a strong motivation to duplicate existing work.
>>>> 
>>>> Alia
>>>> 
>>>> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu <[email-masked]>
>> wrote:
>>>>> I was wondering if PCE and IRS could have overlapping functionality.
>>>>> 
>>>>> Meaning, can an IRS interface user at both ends (node and 
>>>>> controller) be a
>>>> non-PCE entity and perform
>>>>> the same service as what PCE does?
>>>>> 
>>>>> It seems like you are saying that could work co-operatively...
>>>>> 
>>>>> Thanks,
>>>>> himanshu
>>>> 
>>>> ==snip===
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: Acee Lindem <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Fri, 17 Aug 2012 12:30:17 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--Apple-Mail-27--305886237
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Aug 16, 2012, at 12:23 PM, Alia Atlas wrote:

> ACLs as in for BGP policy

I would hope IRS will provision BGP policy in 2012 with a constructs more powerful than ACLs. Perhaps, Routing Policy Specification Language (RFC 2622) or something similar.

Acee 

> or as in policy-based-routing/firewalls?
> Both would be likely needed.
> 
> ifMIB info?  I'm not sure what aspects you are poking at.  In terms of
> reading information for the topology export, yes...  In terms of
> writing state, I don't think so...
> 
> Alia
> 
> On Thu, Aug 16, 2012 at 10:42 AM, Shah, Himanshu <[email-masked]> wrote:
>> This is precisely the answer I was looking for.
>> It's a domain issue. This is how IRS distinguishes itself from OpenFlow/ForCES/GSMP etc etc
>> 
>> Understand the reasoning but was hoping that IRS would provide one uniform interface - top to bottom,
>> so implementers do not have to deal with supporting multiple utilities.
>> 
>> What about ACL (Access Control List), ifMIB specific info etc. (trying to get sense on the lowest layer that IRS will cover)
>> 
>> Thanks,
>> himanshu
>> 
>> 
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 10:57 PM
>> To: Shah, Himanshu
>> Cc: UTTARO, JAMES; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>> 
>> What is the benefit of allowing access to the FIB vs. the associated complexity?
>> If something wants to inject state directly into the forwarding plane, isn't that what ForCES or OpenFlow is for?
>> 
>> Why get into low-level assembly when we've got a C-equiv?  (Still not a higher level language that apps might speak with associated abstractions, but closer).
>> 
>> Alia
> 
> ---snip---
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

--Apple-Mail-27--305886237
Content-Disposition: attachment; filename="smime.p7s"
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64

--Apple-Mail-27--305886237--

From: Thomas Nadeau <[email-masked]>
Date: Fri, 17 Aug 2012 10:09:17 -0400
To: Mach Chen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJUlMgY29tbWVudHM=?X-BeenThere: [email-masked]

On Aug 16, 2012, at 10:38 PM, Mach Chen <[email-masked]> wrote:

> Hi Alia,
> 
> It's great to define uniform interfaces to the applications, but I am not sure whether the IRS interfaces could be directly used by the applications, in the IRS framework, the applications talk to the IRS agents, IMHO, the IRS agent (it may be the controller or orchestrator role from the SDN point of view, and the IRS interfaces are the southbound interfaces ) should shield the variety of the IRS interfaces.  

The idea is definitely to allow direct use of the interface of that is operationally desired.

Tom 

> And I agree that we should currently focus on the use cases and then define a clear scope. Here is a rough SDN related use case draft (http://tools.ietf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I am not sure this is related to IRS. 
> 
> Best regards,
> Mach
> 
>> -----é‚®ä»¶åŽŸä»¶-----
>> å‘ä»¶äºº: Alia Atlas [mailto:[email-masked]]
>> å‘é€æ—¶é—´: 2012å¹´8æœˆ17æ—¥ 10:13
>> æ”¶ä»¶äºº: Mach Chen
>> æŠ„é€: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K (Pranjal);
>> [email-masked]
>> ä¸»é¢˜: Re: ç­”å¤: [irs-discuss] IRS comments
>> 
>> Hi Mach,
>> 
>> Right - that is one reason why I'm not sure that a CSPF computation
>> piece is needed for the RSVP sub-interface.  On the other side,
>> there's benefit to not requiring an application to understand too many
>> different protocols.
>> 
>> We need to discuss what scope makes sense for the sub-interfaces.  I
>> think the use-cases will drive this.
>> 
>> Alia
>> 
>> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen <[email-masked]>
>> wrote:
>>> Hi Alia,
>>> 
>>> I am a little confused, the said RSVP sub-interface (on-demand CSPF interface)
>> seems what exactly PCEP does today. My understanding of IRS is that it may be
>> complementary on topology discovery.
>>> 
>>> Best regards,
>>> Mach
>>> 
>>>> -----é‚®ä»¶åŽŸä»¶-----
>>>> å‘ä»¶äºº: [email-masked] [mailto:[email-masked]]
>> ä»£
>>>> è¡¨ Alia Atlas
>>>> å‘é€æ—¶é—´: 2012å¹´8æœˆ17æ—¥ 9:45
>>>> æ”¶ä»¶äºº: Shah, Himanshu
>>>> æŠ„é€: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); [email-masked]
>>>> ä¸»é¢˜: Re: [irs-discuss] IRS comments
>>>> 
>>>> I'm not entirely clear on the model or question you are asking.  An
>>>> application could learn topology via IRS to the appropriate IRS
>>>> agents, do CSPF computations, and support a signaling/CSPF-like
>>>> sub-interface (if we define such for IRS) as an IRS agent.  Another
>>>> application could query the first for the CSPF results and then use
>>>> IRS to trigger signaling on the appropriate device.
>>>> 
>>>> I'm not sure if it makes sense to have an IRS sub-interface that
>>>> requests CSPF computation, but it might come as part of an RSVP
>>>> sub-interface to trigger signaling.  We'll have to see about
>>>> use-cases.
>>>> 
>>>> I don't see a strong motivation to duplicate existing work.
>>>> 
>>>> Alia
>>>> 
>>>> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu <[email-masked]>
>> wrote:
>>>>> I was wondering if PCE and IRS could have overlapping functionality.
>>>>> 
>>>>> Meaning, can an IRS interface user at both ends (node and controller) be a
>>>> non-PCE entity and perform
>>>>> the same service as what PCE does?
>>>>> 
>>>>> It seems like you are saying that could work co-operatively...
>>>>> 
>>>>> Thanks,
>>>>> himanshu
>>>> 
>>>> ==snip===
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Fri, 17 Aug 2012 08:45:01 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: Ramon Casellas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Hi Alia,
          
"Whether centralized SPF compute is a good idea probably depends greatly on the use-case and details of the architecture.  I haven't seen ones that convince me yet, but I haven't been hunting them either."

Yes, this is the point. I am not convinced either. Unless we see strong realistic use case we probably shouldn't discuss this further.

Thanks,
Pranjal

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 7:46 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Ramon Casellas; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Pranjal,

Sure - IRS is to provide an Interface to the Routing System.  If part
of the routing system isn't co-located on the forwarding device, then
it'd be good for the IRS data-models and such to work with it.  That's
hard when it is a moving target.

My point about LFA/MRT/IP-FRR is simply that if the SPF compute is
remote, then that will impact the convergence time.  At that point for
an architecture, there are basically two choices - deal with longer
periods of traffic loss or pre-compute and install alternates to use
in the case of a local failure.   The longer FIB convergence time
could thus be mitigated.

Whether centralized SPF compute is a good idea probably depends
greatly on the use-case and details of the architecture.  I haven't
seen ones that convince me yet, but I haven't been hunting them
either.

Alia

On Thu, Aug 16, 2012 at 10:19 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> I believe if IRS needs to address centralized SPF compute then it needs to be a generic approach, irrespective of whether a topology offers LFA/MRT. Thus I see a limited scope since FIB convergence would be a major concern in general, although this is a too early statement to make. As I mentioned I would be very cautious on such approach.
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 7:11 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Ramon Casellas; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> If there are always IP-FRR alternates that can be used and only a
> single covered failure has happened, then the slow path reconvergence
> needn't impact traffic (ignoring the issue of u-loops which we do
> understand how to handle).  As for MRT, the advantage is that it
> guarantees there'll always be an alternate, unlike LFA.  Some method
> has to be used to get that level of coverage - depending on how bad
> the FIB convergence times would be.
>
> Alia
>
> On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal)
> <[email-masked]> wrote:
>>
>> IP-FRR/LFA can mitigate one aspect of the problem but most of FIB convergence issues in FRR based solutions arise rather during slow
>> path convergence after a fast failover. When SPF recompute after
>> the FRR switch requires touching the flows again (e.g SPF recompute
>> chose a new primary next-hop) then tricks in FIB convergence matters.
>> So I would be a bit cautious...MRT etc may not be available in all
>> topologies.
>>
>> Thanks,
>> Pranjal
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Thursday, August 16, 2012 6:50 PM
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Ramon Casellas; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>>> Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally.
>>
>> [Alia] What it could accomplish is allowing other types of algorithms
>> than simple SPF for computing routes.   As for FIB convergence, this
>> is certainly a concern.  I do think that fast-reroute technology could
>> be used to mitigate the problem - but only really for single failures.
>>
>>> As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS.
>>>
>>> Thanks,
>>> Pranjal
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Ramon Casellas [mailto:[email-masked]]
>>> Sent: Thursday, August 16, 2012 9:58 AM
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
>>>> "LSDB (I saw an email which talks about reducing IGP to link
>>>>> distribution protocol and running SPF in centralized network
>>>>> controller)"
>>>> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
>>>> precisely that would help a lot.
>>>>
>>>> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>>>>
>>>> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>>>>
>>>> Is that correct? How different this going to be from PCE?
>>>>
>>>
>>>
>>> Pranjal, all,
>>>
>>> My two cents. Apologies if this is well known, I am not sure I fully
>>> grasped your question...
>>>
>>> IMHO, the idea of separating LSA flooding from CSPF computation has
>>> indeed been a current topic for a while, and when it is tied to the idea
>>> of offloading the CSPF computation to a dedicated centralized server
>>> (for example a PCE),  I would guess/say that this is usually scoped and
>>> applies to the case when one formally decouples the control plane from
>>> the data plane (thus constructing a LSDB and establishing adjacencies in
>>> the control plane network and also constructing a separated Traffic
>>> Engineering Database or TED, which is described via opaque LSAs).
>>>
>>> In this particular scenario, the CSPF refers to /applies to the
>>> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for
>>> the addresses in the DCN. In other words, OSPF-TE is used to disseminate
>>> data plane (TE) link/node attribute changes (in addition to what OSFPv2
>>> already does) and for this establishes routing adjacencies and the PCE
>>> performs CSPF on the TED, which can be a completely different topology.
>>>
>>> However, regarding your question "how different from a PCE", I would say
>>> these are complementary : first a) the PCE architecture does not specify
>>> how it obtains the Traffic Engineering Database (TED) to construct the
>>> directed graph on which it operates (i.e., performs CSPF, usually upon
>>> request); the PCE does not usually care much about the control plane
>>> topology and, b) what you refer to "push to each router" and "inject
>>> entries into the RIB" is completely orthogonal to a PCE.
>>>
>>> For a), and as stated previously in the list, a common way is to be a
>>> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to
>>> contact a topology server or NMS that has the current topology  (TED).
>>> In other words, a PCE is a decoupled functional component and the
>>> protocol (PCEP) only specifies the interface to request path
>>> computations. Even if one uses a PCE and a lightweight LSA flooding
>>> protocol, SPF still needs to be executed by nodes to "forward" control
>>> packets, usually using the uncontrained shortest IP route. For b) note
>>> that, as of now, there is no standard way by which a PCE can configure
>>> the dataplane by itself. By "configure the dataplane" one can mean to
>>> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure
>>> the cross-connects via OpenFlow or to set up state in the datapath
>>> (could even be configuring the RIB), somehow.
>>>
>>> Recently, Ed has started work in stateful PCE, and it is possible that
>>> in the future it will have the capability to "command" the establishment
>>> of connections.
>>>
>>> In summary, I see the (generic) relationship between PCE and IRS in two
>>> main ways:
>>>
>>> * As a means to communicate / obtain the TED, typically constructed via
>>> OSPF-TE opaque LSAs. This would be an alternative to existing methods /
>>> current practice. Another main driver for this is the Hierarchical PCE
>>> (H-PCE) in case a parent PCE needs to know about an (aggregated)
>>> topology within a (child) domain, since parent / child PCEs may not be
>>> in the same IGP area.
>>> In this sense, and as stated in the list, for this, other considered
>>> solutions are BGPLS / north bound interfaces or to use notify (PCNtf)
>>> messages wrapping TE LSAs for this.
>>>
>>> * As a means to define data plane state (much like OpenFlow) once a Path
>>> has been computed.
>>>
>>> Imho these are two areas which the PCE architecture and protocol do not
>>> currently cover and in which an architecture such as IRS could be helpful.
>>>
>>> Hope this helps (a little!)
>>>
>>> Best regards
>>>
>>> Ramon
>>>
>>> --
>>> Ramon Casellas, Ph.D.
>>> Research Associate - Optical Networking Area --http://wikiona.cttc.es
>>> CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
>>> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
>>> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
>>>
>>>
>>>

From: Mach Chen <[email-masked]>
To: Alia Atlas <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [irs-discuss] =?gb2312?b?tPC4tDogtPC4tDogtPC4tDogIElSUyBjb21tZW50?= =?gb2312?b?cw=?X-BeenThere: [email-masked]

Date: Thu, 16 Aug 2012 22:51:21 -0400
From: Alia Atlas <[email-masked]>
To: Mach Chen <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] =?gb2312?b?tPC4tDogtPC4tDogIElSUyBjb21tZW50cw=?X-BeenThere: [email-masked]

Hi Mach,

The IRS agent is co-located with the portion of the routing system
that it provides an interface too.  I think you might be confused
about that - since the IRS agent isn't part of the controller or
orchestrator unless that is offering part of the routing system.
So - I disagree about the impact of multiple protocols.

Rather than look at the various general SDN use-cases, it is much more
interesting to look at use-cases for IRS.  If you care to look at that
draft and find something of relevance for IRS, please do let the list
know.

Alia

On Thu, Aug 16, 2012 at 10:38 PM, Mach Chen <[email-masked]> wrote:
> Hi Alia,
>
> It's great to define uniform interfaces to the applications, but I am not sure whether the IRS interfaces could be directly used by the applications, in the IRS framework, the applications talk to the IRS agents, IMHO, the IRS agent (it may be the controller or orchestrator role from the SDN point of view, and the IRS interfaces are the southbound interfaces ) should shield the variety of the IRS interfaces.
>
> And I agree that we should currently focus on the use cases and then define a clear scope. Here is a rough SDN related use case draft (http://tools.ietf.org/html/draft-mm-sdn-vc-vn-on-demand-use-case-01), I am not sure this is related to IRS.
>
> Best regards,
> Mach
>
>> -----ÓÊ¼þÔ­¼þ-----
>> ·¢¼þÈË: Alia Atlas [mailto:[email-masked]]
>> ·¢ËÍÊ±¼ä: 2012Äê8ÔÂ17ÈÕ 10:13
>> ÊÕ¼þÈË: Mach Chen
>> ³ËÍ: Shah, Himanshu; UTTARO, JAMES; Dutta, Pranjal K (Pranjal);
>> [email-masked]
>> Ö÷Ìâ: Re: ´ð¸´: [irs-discuss] IRS comments
>>
>> Hi Mach,
>>
>> Right - that is one reason why I'm not sure that a CSPF computation
>> piece is needed for the RSVP sub-interface.  On the other side,
>> there's benefit to not requiring an application to understand too many
>> different protocols.
>>
>> We need to discuss what scope makes sense for the sub-interfaces.  I
>> think the use-cases will drive this.
>>
>> Alia
>>
>> On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen <[email-masked]>
>> wrote:
>> > Hi Alia,
>> >
>> > I am a little confused, the said RSVP sub-interface (on-demand CSPF interface)
>> seems what exactly PCEP does today. My understanding of IRS is that it may be
>> complementary on topology discovery.
>> >
>> > Best regards,
>> > Mach
>> >
>> >> -----ÓÊ¼þÔ­¼þ-----
>> >> ·¢¼þÈË: [email-masked] [mailto:[email-masked]]
>> ´ú
>> >> ±í Alia Atlas
>> >> ·¢ËÍÊ±¼ä: 2012Äê8ÔÂ17ÈÕ 9:45
>> >> ÊÕ¼þÈË: Shah, Himanshu
>> >> ³ËÍ: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); [email-masked]
>> >> Ö÷Ìâ: Re: [irs-discuss] IRS comments
>> >>
>> >> I'm not entirely clear on the model or question you are asking.  An
>> >> application could learn topology via IRS to the appropriate IRS
>> >> agents, do CSPF computations, and support a signaling/CSPF-like
>> >> sub-interface (if we define such for IRS) as an IRS agent.  Another
>> >> application could query the first for the CSPF results and then use
>> >> IRS to trigger signaling on the appropriate device.
>> >>
>> >> I'm not sure if it makes sense to have an IRS sub-interface that
>> >> requests CSPF computation, but it might come as part of an RSVP
>> >> sub-interface to trigger signaling.  We'll have to see about
>> >> use-cases.
>> >>
>> >> I don't see a strong motivation to duplicate existing work.
>> >>
>> >> Alia
>> >>
>> >> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu <[email-masked]>
>> wrote:
>> >> > I was wondering if PCE and IRS could have overlapping functionality.
>> >> >
>> >> > Meaning, can an IRS interface user at both ends (node and controller) be a
>> >> non-PCE entity and perform
>> >> > the same service as what PCE does?
>> >> >
>> >> > It seems like you are saying that could work co-operatively...
>> >> >
>> >> > Thanks,
>> >> > himanshu
>> >>
>> >> ==snip===
>> >> _______________________________________________
>> >> irs-discuss mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Thu, 16 Aug 2012 22:46:17 -0400
From: Alia Atlas <[email-masked]>
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: Ramon Casellas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Pranjal,

Sure - IRS is to provide an Interface to the Routing System.  If part
of the routing system isn't co-located on the forwarding device, then
it'd be good for the IRS data-models and such to work with it.  That's
hard when it is a moving target.

My point about LFA/MRT/IP-FRR is simply that if the SPF compute is
remote, then that will impact the convergence time.  At that point for
an architecture, there are basically two choices - deal with longer
periods of traffic loss or pre-compute and install alternates to use
in the case of a local failure.   The longer FIB convergence time
could thus be mitigated.

Whether centralized SPF compute is a good idea probably depends
greatly on the use-case and details of the architecture.  I haven't
seen ones that convince me yet, but I haven't been hunting them
either.

Alia

On Thu, Aug 16, 2012 at 10:19 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> I believe if IRS needs to address centralized SPF compute then it needs to be a generic approach, irrespective of whether a topology offers LFA/MRT. Thus I see a limited scope since FIB convergence would be a major concern in general, although this is a too early statement to make. As I mentioned I would be very cautious on such approach.
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 7:11 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Ramon Casellas; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> If there are always IP-FRR alternates that can be used and only a
> single covered failure has happened, then the slow path reconvergence
> needn't impact traffic (ignoring the issue of u-loops which we do
> understand how to handle).  As for MRT, the advantage is that it
> guarantees there'll always be an alternate, unlike LFA.  Some method
> has to be used to get that level of coverage - depending on how bad
> the FIB convergence times would be.
>
> Alia
>
> On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal)
> <[email-masked]> wrote:
>>
>> IP-FRR/LFA can mitigate one aspect of the problem but most of FIB convergence issues in FRR based solutions arise rather during slow
>> path convergence after a fast failover. When SPF recompute after
>> the FRR switch requires touching the flows again (e.g SPF recompute
>> chose a new primary next-hop) then tricks in FIB convergence matters.
>> So I would be a bit cautious...MRT etc may not be available in all
>> topologies.
>>
>> Thanks,
>> Pranjal
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Thursday, August 16, 2012 6:50 PM
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Ramon Casellas; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
>> <[email-masked]> wrote:
>>> Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally.
>>
>> [Alia] What it could accomplish is allowing other types of algorithms
>> than simple SPF for computing routes.   As for FIB convergence, this
>> is certainly a concern.  I do think that fast-reroute technology could
>> be used to mitigate the problem - but only really for single failures.
>>
>>> As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS.
>>>
>>> Thanks,
>>> Pranjal
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Ramon Casellas [mailto:[email-masked]]
>>> Sent: Thursday, August 16, 2012 9:58 AM
>>> To: Dutta, Pranjal K (Pranjal)
>>> Cc: Alia Atlas; [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
>>>> "LSDB (I saw an email which talks about reducing IGP to link
>>>>> distribution protocol and running SPF in centralized network
>>>>> controller)"
>>>> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
>>>> precisely that would help a lot.
>>>>
>>>> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>>>>
>>>> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>>>>
>>>> Is that correct? How different this going to be from PCE?
>>>>
>>>
>>>
>>> Pranjal, all,
>>>
>>> My two cents. Apologies if this is well known, I am not sure I fully
>>> grasped your question...
>>>
>>> IMHO, the idea of separating LSA flooding from CSPF computation has
>>> indeed been a current topic for a while, and when it is tied to the idea
>>> of offloading the CSPF computation to a dedicated centralized server
>>> (for example a PCE),  I would guess/say that this is usually scoped and
>>> applies to the case when one formally decouples the control plane from
>>> the data plane (thus constructing a LSDB and establishing adjacencies in
>>> the control plane network and also constructing a separated Traffic
>>> Engineering Database or TED, which is described via opaque LSAs).
>>>
>>> In this particular scenario, the CSPF refers to /applies to the
>>> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for
>>> the addresses in the DCN. In other words, OSPF-TE is used to disseminate
>>> data plane (TE) link/node attribute changes (in addition to what OSFPv2
>>> already does) and for this establishes routing adjacencies and the PCE
>>> performs CSPF on the TED, which can be a completely different topology.
>>>
>>> However, regarding your question "how different from a PCE", I would say
>>> these are complementary : first a) the PCE architecture does not specify
>>> how it obtains the Traffic Engineering Database (TED) to construct the
>>> directed graph on which it operates (i.e., performs CSPF, usually upon
>>> request); the PCE does not usually care much about the control plane
>>> topology and, b) what you refer to "push to each router" and "inject
>>> entries into the RIB" is completely orthogonal to a PCE.
>>>
>>> For a), and as stated previously in the list, a common way is to be a
>>> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to
>>> contact a topology server or NMS that has the current topology  (TED).
>>> In other words, a PCE is a decoupled functional component and the
>>> protocol (PCEP) only specifies the interface to request path
>>> computations. Even if one uses a PCE and a lightweight LSA flooding
>>> protocol, SPF still needs to be executed by nodes to "forward" control
>>> packets, usually using the uncontrained shortest IP route. For b) note
>>> that, as of now, there is no standard way by which a PCE can configure
>>> the dataplane by itself. By "configure the dataplane" one can mean to
>>> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure
>>> the cross-connects via OpenFlow or to set up state in the datapath
>>> (could even be configuring the RIB), somehow.
>>>
>>> Recently, Ed has started work in stateful PCE, and it is possible that
>>> in the future it will have the capability to "command" the establishment
>>> of connections.
>>>
>>> In summary, I see the (generic) relationship between PCE and IRS in two
>>> main ways:
>>>
>>> * As a means to communicate / obtain the TED, typically constructed via
>>> OSPF-TE opaque LSAs. This would be an alternative to existing methods /
>>> current practice. Another main driver for this is the Hierarchical PCE
>>> (H-PCE) in case a parent PCE needs to know about an (aggregated)
>>> topology within a (child) domain, since parent / child PCEs may not be
>>> in the same IGP area.
>>> In this sense, and as stated in the list, for this, other considered
>>> solutions are BGPLS / north bound interfaces or to use notify (PCNtf)
>>> messages wrapping TE LSAs for this.
>>>
>>> * As a means to define data plane state (much like OpenFlow) once a Path
>>> has been computed.
>>>
>>> Imho these are two areas which the PCE architecture and protocol do not
>>> currently cover and in which an architecture such as IRS could be helpful.
>>>
>>> Hope this helps (a little!)
>>>
>>> Best regards
>>>
>>> Ramon
>>>
>>> --
>>> Ramon Casellas, Ph.D.
>>> Research Associate - Optical Networking Area --http://wikiona.cttc.es
>>> CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
>>> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
>>> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
>>>
>>>
>>>

From: Mach Chen <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Fri, 17 Aug 2012 02:38:02 +0000
Accept-Language: en-US, zh-CN
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [irs-discuss] =?gb2312?b?tPC4tDogtPC4tDogIElSUyBjb21tZW50cw=?X-BeenThere: [email-masked]

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Fri, 17 Aug 2012 07:49:07 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: Ramon Casellas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I believe if IRS needs to address centralized SPF compute then it needs to be a generic approach, irrespective of whether a topology offers LFA/MRT. Thus I see a limited scope since FIB convergence would be a major concern in general, although this is a too early statement to make. As I mentioned I would be very cautious on such approach.

Thanks,
Pranjal 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 7:11 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Ramon Casellas; [email-masked]
Subject: Re: [irs-discuss] IRS comments

If there are always IP-FRR alternates that can be used and only a
single covered failure has happened, then the slow path reconvergence
needn't impact traffic (ignoring the issue of u-loops which we do
understand how to handle).  As for MRT, the advantage is that it
guarantees there'll always be an alternate, unlike LFA.  Some method
has to be used to get that level of coverage - depending on how bad
the FIB convergence times would be.

Alia

On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
>
> IP-FRR/LFA can mitigate one aspect of the problem but most of FIB convergence issues in FRR based solutions arise rather during slow
> path convergence after a fast failover. When SPF recompute after
> the FRR switch requires touching the flows again (e.g SPF recompute
> chose a new primary next-hop) then tricks in FIB convergence matters.
> So I would be a bit cautious...MRT etc may not be available in all
> topologies.
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 6:50 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Ramon Casellas; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
> <[email-masked]> wrote:
>> Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally.
>
> [Alia] What it could accomplish is allowing other types of algorithms
> than simple SPF for computing routes.   As for FIB convergence, this
> is certainly a concern.  I do think that fast-reroute technology could
> be used to mitigate the problem - but only really for single failures.
>
>> As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS.
>>
>> Thanks,
>> Pranjal
>>
>>
>>
>> -----Original Message-----
>> From: Ramon Casellas [mailto:[email-masked]]
>> Sent: Thursday, August 16, 2012 9:58 AM
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Alia Atlas; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
>>> "LSDB (I saw an email which talks about reducing IGP to link
>>>> distribution protocol and running SPF in centralized network
>>>> controller)"
>>> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
>>> precisely that would help a lot.
>>>
>>> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>>>
>>> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>>>
>>> Is that correct? How different this going to be from PCE?
>>>
>>
>>
>> Pranjal, all,
>>
>> My two cents. Apologies if this is well known, I am not sure I fully
>> grasped your question...
>>
>> IMHO, the idea of separating LSA flooding from CSPF computation has
>> indeed been a current topic for a while, and when it is tied to the idea
>> of offloading the CSPF computation to a dedicated centralized server
>> (for example a PCE),  I would guess/say that this is usually scoped and
>> applies to the case when one formally decouples the control plane from
>> the data plane (thus constructing a LSDB and establishing adjacencies in
>> the control plane network and also constructing a separated Traffic
>> Engineering Database or TED, which is described via opaque LSAs).
>>
>> In this particular scenario, the CSPF refers to /applies to the
>> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for
>> the addresses in the DCN. In other words, OSPF-TE is used to disseminate
>> data plane (TE) link/node attribute changes (in addition to what OSFPv2
>> already does) and for this establishes routing adjacencies and the PCE
>> performs CSPF on the TED, which can be a completely different topology.
>>
>> However, regarding your question "how different from a PCE", I would say
>> these are complementary : first a) the PCE architecture does not specify
>> how it obtains the Traffic Engineering Database (TED) to construct the
>> directed graph on which it operates (i.e., performs CSPF, usually upon
>> request); the PCE does not usually care much about the control plane
>> topology and, b) what you refer to "push to each router" and "inject
>> entries into the RIB" is completely orthogonal to a PCE.
>>
>> For a), and as stated previously in the list, a common way is to be a
>> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to
>> contact a topology server or NMS that has the current topology  (TED).
>> In other words, a PCE is a decoupled functional component and the
>> protocol (PCEP) only specifies the interface to request path
>> computations. Even if one uses a PCE and a lightweight LSA flooding
>> protocol, SPF still needs to be executed by nodes to "forward" control
>> packets, usually using the uncontrained shortest IP route. For b) note
>> that, as of now, there is no standard way by which a PCE can configure
>> the dataplane by itself. By "configure the dataplane" one can mean to
>> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure
>> the cross-connects via OpenFlow or to set up state in the datapath
>> (could even be configuring the RIB), somehow.
>>
>> Recently, Ed has started work in stateful PCE, and it is possible that
>> in the future it will have the capability to "command" the establishment
>> of connections.
>>
>> In summary, I see the (generic) relationship between PCE and IRS in two
>> main ways:
>>
>> * As a means to communicate / obtain the TED, typically constructed via
>> OSPF-TE opaque LSAs. This would be an alternative to existing methods /
>> current practice. Another main driver for this is the Hierarchical PCE
>> (H-PCE) in case a parent PCE needs to know about an (aggregated)
>> topology within a (child) domain, since parent / child PCEs may not be
>> in the same IGP area.
>> In this sense, and as stated in the list, for this, other considered
>> solutions are BGPLS / north bound interfaces or to use notify (PCNtf)
>> messages wrapping TE LSAs for this.
>>
>> * As a means to define data plane state (much like OpenFlow) once a Path
>> has been computed.
>>
>> Imho these are two areas which the PCE architecture and protocol do not
>> currently cover and in which an architecture such as IRS could be helpful.
>>
>> Hope this helps (a little!)
>>
>> Best regards
>>
>> Ramon
>>
>> --
>> Ramon Casellas, Ph.D.
>> Research Associate - Optical Networking Area --http://wikiona.cttc.es
>> CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
>> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
>> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
>>
>>
>>

Date: Thu, 16 Aug 2012 22:13:16 -0400
From: Alia Atlas <[email-masked]>
To: Mach Chen <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] =?gb2312?b?tPC4tDogIElSUyBjb21tZW50cw=?X-BeenThere: [email-masked]

Hi Mach,

Right - that is one reason why I'm not sure that a CSPF computation
piece is needed for the RSVP sub-interface.  On the other side,
there's benefit to not requiring an application to understand too many
different protocols.

We need to discuss what scope makes sense for the sub-interfaces.  I
think the use-cases will drive this.

Alia

On Thu, Aug 16, 2012 at 10:06 PM, Mach Chen <[email-masked]> wrote:
> Hi Alia,
>
> I am a little confused, the said RSVP sub-interface (on-demand CSPF interface) seems what exactly PCEP does today. My understanding of IRS is that it may be complementary on topology discovery.
>
> Best regards,
> Mach
>
>> -----ÓÊ¼þÔ­¼þ-----
>> ·¢¼þÈË: [email-masked] [mailto:[email-masked]] ´ú
>> ±í Alia Atlas
>> ·¢ËÍÊ±¼ä: 2012Äê8ÔÂ17ÈÕ 9:45
>> ÊÕ¼þÈË: Shah, Himanshu
>> ³ËÍ: UTTARO, JAMES; Dutta, Pranjal K (Pranjal); [email-masked]
>> Ö÷Ìâ: Re: [irs-discuss] IRS comments
>>
>> I'm not entirely clear on the model or question you are asking.  An
>> application could learn topology via IRS to the appropriate IRS
>> agents, do CSPF computations, and support a signaling/CSPF-like
>> sub-interface (if we define such for IRS) as an IRS agent.  Another
>> application could query the first for the CSPF results and then use
>> IRS to trigger signaling on the appropriate device.
>>
>> I'm not sure if it makes sense to have an IRS sub-interface that
>> requests CSPF computation, but it might come as part of an RSVP
>> sub-interface to trigger signaling.  We'll have to see about
>> use-cases.
>>
>> I don't see a strong motivation to duplicate existing work.
>>
>> Alia
>>
>> On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu <[email-masked]> wrote:
>> > I was wondering if PCE and IRS could have overlapping functionality.
>> >
>> > Meaning, can an IRS interface user at both ends (node and controller) be a
>> non-PCE entity and perform
>> > the same service as what PCE does?
>> >
>> > It seems like you are saying that could work co-operatively...
>> >
>> > Thanks,
>> > himanshu
>>
>> ==snip===
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Thu, 16 Aug 2012 22:11:24 -0400
From: Alia Atlas <[email-masked]>
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: Ramon Casellas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

If there are always IP-FRR alternates that can be used and only a
single covered failure has happened, then the slow path reconvergence
needn't impact traffic (ignoring the issue of u-loops which we do
understand how to handle).  As for MRT, the advantage is that it
guarantees there'll always be an alternate, unlike LFA.  Some method
has to be used to get that level of coverage - depending on how bad
the FIB convergence times would be.

Alia

On Thu, Aug 16, 2012 at 10:06 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
>
> IP-FRR/LFA can mitigate one aspect of the problem but most of FIB convergence issues in FRR based solutions arise rather during slow
> path convergence after a fast failover. When SPF recompute after
> the FRR switch requires touching the flows again (e.g SPF recompute
> chose a new primary next-hop) then tricks in FIB convergence matters.
> So I would be a bit cautious...MRT etc may not be available in all
> topologies.
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 6:50 PM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Ramon Casellas; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
> <[email-masked]> wrote:
>> Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally.
>
> [Alia] What it could accomplish is allowing other types of algorithms
> than simple SPF for computing routes.   As for FIB convergence, this
> is certainly a concern.  I do think that fast-reroute technology could
> be used to mitigate the problem - but only really for single failures.
>
>> As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS.
>>
>> Thanks,
>> Pranjal
>>
>>
>>
>> -----Original Message-----
>> From: Ramon Casellas [mailto:[email-masked]]
>> Sent: Thursday, August 16, 2012 9:58 AM
>> To: Dutta, Pranjal K (Pranjal)
>> Cc: Alia Atlas; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
>>> "LSDB (I saw an email which talks about reducing IGP to link
>>>> distribution protocol and running SPF in centralized network
>>>> controller)"
>>> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
>>> precisely that would help a lot.
>>>
>>> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>>>
>>> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>>>
>>> Is that correct? How different this going to be from PCE?
>>>
>>
>>
>> Pranjal, all,
>>
>> My two cents. Apologies if this is well known, I am not sure I fully
>> grasped your question...
>>
>> IMHO, the idea of separating LSA flooding from CSPF computation has
>> indeed been a current topic for a while, and when it is tied to the idea
>> of offloading the CSPF computation to a dedicated centralized server
>> (for example a PCE),  I would guess/say that this is usually scoped and
>> applies to the case when one formally decouples the control plane from
>> the data plane (thus constructing a LSDB and establishing adjacencies in
>> the control plane network and also constructing a separated Traffic
>> Engineering Database or TED, which is described via opaque LSAs).
>>
>> In this particular scenario, the CSPF refers to /applies to the
>> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for
>> the addresses in the DCN. In other words, OSPF-TE is used to disseminate
>> data plane (TE) link/node attribute changes (in addition to what OSFPv2
>> already does) and for this establishes routing adjacencies and the PCE
>> performs CSPF on the TED, which can be a completely different topology.
>>
>> However, regarding your question "how different from a PCE", I would say
>> these are complementary : first a) the PCE architecture does not specify
>> how it obtains the Traffic Engineering Database (TED) to construct the
>> directed graph on which it operates (i.e., performs CSPF, usually upon
>> request); the PCE does not usually care much about the control plane
>> topology and, b) what you refer to "push to each router" and "inject
>> entries into the RIB" is completely orthogonal to a PCE.
>>
>> For a), and as stated previously in the list, a common way is to be a
>> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to
>> contact a topology server or NMS that has the current topology  (TED).
>> In other words, a PCE is a decoupled functional component and the
>> protocol (PCEP) only specifies the interface to request path
>> computations. Even if one uses a PCE and a lightweight LSA flooding
>> protocol, SPF still needs to be executed by nodes to "forward" control
>> packets, usually using the uncontrained shortest IP route. For b) note
>> that, as of now, there is no standard way by which a PCE can configure
>> the dataplane by itself. By "configure the dataplane" one can mean to
>> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure
>> the cross-connects via OpenFlow or to set up state in the datapath
>> (could even be configuring the RIB), somehow.
>>
>> Recently, Ed has started work in stateful PCE, and it is possible that
>> in the future it will have the capability to "command" the establishment
>> of connections.
>>
>> In summary, I see the (generic) relationship between PCE and IRS in two
>> main ways:
>>
>> * As a means to communicate / obtain the TED, typically constructed via
>> OSPF-TE opaque LSAs. This would be an alternative to existing methods /
>> current practice. Another main driver for this is the Hierarchical PCE
>> (H-PCE) in case a parent PCE needs to know about an (aggregated)
>> topology within a (child) domain, since parent / child PCEs may not be
>> in the same IGP area.
>> In this sense, and as stated in the list, for this, other considered
>> solutions are BGPLS / north bound interfaces or to use notify (PCNtf)
>> messages wrapping TE LSAs for this.
>>
>> * As a means to define data plane state (much like OpenFlow) once a Path
>> has been computed.
>>
>> Imho these are two areas which the PCE architecture and protocol do not
>> currently cover and in which an architecture such as IRS could be helpful.
>>
>> Hope this helps (a little!)
>>
>> Best regards
>>
>> Ramon
>>
>> --
>> Ramon Casellas, Ph.D.
>> Research Associate - Optical Networking Area --http://wikiona.cttc.es
>> CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
>> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
>> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
>>
>>
>>

From: Mach Chen <[email-masked]>
To: Alia Atlas <[email-masked]>, "Shah, Himanshu" <[email-masked]>
Date: Fri, 17 Aug 2012 02:06:54 +0000
Accept-Language: en-US, zh-CN
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [irs-discuss] =?gb2312?b?tPC4tDogIElSUyBjb21tZW50cw=?X-BeenThere: [email-masked]

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Fri, 17 Aug 2012 07:36:14 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: Ramon Casellas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

IP-FRR/LFA can mitigate one aspect of the problem but most of FIB convergence issues in FRR based solutions arise rather during slow 
path convergence after a fast failover. When SPF recompute after 
the FRR switch requires touching the flows again (e.g SPF recompute 
chose a new primary next-hop) then tricks in FIB convergence matters. 
So I would be a bit cautious...MRT etc may not be available in all 
topologies.

Thanks,
Pranjal 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 6:50 PM
To: Dutta, Pranjal K (Pranjal)
Cc: Ramon Casellas; [email-masked]
Subject: Re: [irs-discuss] IRS comments

On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally.

[Alia] What it could accomplish is allowing other types of algorithms
than simple SPF for computing routes.   As for FIB convergence, this
is certainly a concern.  I do think that fast-reroute technology could
be used to mitigate the problem - but only really for single failures.

> As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS.
>
> Thanks,
> Pranjal
>
>
>
> -----Original Message-----
> From: Ramon Casellas [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 9:58 AM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Alia Atlas; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
>> "LSDB (I saw an email which talks about reducing IGP to link
>>> distribution protocol and running SPF in centralized network
>>> controller)"
>> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
>> precisely that would help a lot.
>>
>> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>>
>> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>>
>> Is that correct? How different this going to be from PCE?
>>
>
>
> Pranjal, all,
>
> My two cents. Apologies if this is well known, I am not sure I fully
> grasped your question...
>
> IMHO, the idea of separating LSA flooding from CSPF computation has
> indeed been a current topic for a while, and when it is tied to the idea
> of offloading the CSPF computation to a dedicated centralized server
> (for example a PCE),  I would guess/say that this is usually scoped and
> applies to the case when one formally decouples the control plane from
> the data plane (thus constructing a LSDB and establishing adjacencies in
> the control plane network and also constructing a separated Traffic
> Engineering Database or TED, which is described via opaque LSAs).
>
> In this particular scenario, the CSPF refers to /applies to the
> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for
> the addresses in the DCN. In other words, OSPF-TE is used to disseminate
> data plane (TE) link/node attribute changes (in addition to what OSFPv2
> already does) and for this establishes routing adjacencies and the PCE
> performs CSPF on the TED, which can be a completely different topology.
>
> However, regarding your question "how different from a PCE", I would say
> these are complementary : first a) the PCE architecture does not specify
> how it obtains the Traffic Engineering Database (TED) to construct the
> directed graph on which it operates (i.e., performs CSPF, usually upon
> request); the PCE does not usually care much about the control plane
> topology and, b) what you refer to "push to each router" and "inject
> entries into the RIB" is completely orthogonal to a PCE.
>
> For a), and as stated previously in the list, a common way is to be a
> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to
> contact a topology server or NMS that has the current topology  (TED).
> In other words, a PCE is a decoupled functional component and the
> protocol (PCEP) only specifies the interface to request path
> computations. Even if one uses a PCE and a lightweight LSA flooding
> protocol, SPF still needs to be executed by nodes to "forward" control
> packets, usually using the uncontrained shortest IP route. For b) note
> that, as of now, there is no standard way by which a PCE can configure
> the dataplane by itself. By "configure the dataplane" one can mean to
> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure
> the cross-connects via OpenFlow or to set up state in the datapath
> (could even be configuring the RIB), somehow.
>
> Recently, Ed has started work in stateful PCE, and it is possible that
> in the future it will have the capability to "command" the establishment
> of connections.
>
> In summary, I see the (generic) relationship between PCE and IRS in two
> main ways:
>
> * As a means to communicate / obtain the TED, typically constructed via
> OSPF-TE opaque LSAs. This would be an alternative to existing methods /
> current practice. Another main driver for this is the Hierarchical PCE
> (H-PCE) in case a parent PCE needs to know about an (aggregated)
> topology within a (child) domain, since parent / child PCEs may not be
> in the same IGP area.
> In this sense, and as stated in the list, for this, other considered
> solutions are BGPLS / north bound interfaces or to use notify (PCNtf)
> messages wrapping TE LSAs for this.
>
> * As a means to define data plane state (much like OpenFlow) once a Path
> has been computed.
>
> Imho these are two areas which the PCE architecture and protocol do not
> currently cover and in which an architecture such as IRS could be helpful.
>
> Hope this helps (a little!)
>
> Best regards
>
> Ramon
>
> --
> Ramon Casellas, Ph.D.
> Research Associate - Optical Networking Area --http://wikiona.cttc.es
> CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
>
>
>

Date: Thu, 16 Aug 2012 21:50:12 -0400
From: Alia Atlas <[email-masked]>
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: Ramon Casellas <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

On Thu, Aug 16, 2012 at 7:41 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally.

[Alia] What it could accomplish is allowing other types of algorithms
than simple SPF for computing routes.   As for FIB convergence, this
is certainly a concern.  I do think that fast-reroute technology could
be used to mitigate the problem - but only really for single failures.

> As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS.
>
> Thanks,
> Pranjal
>
>
>
> -----Original Message-----
> From: Ramon Casellas [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 9:58 AM
> To: Dutta, Pranjal K (Pranjal)
> Cc: Alia Atlas; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
>> "LSDB (I saw an email which talks about reducing IGP to link
>>> distribution protocol and running SPF in centralized network
>>> controller)"
>> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
>> precisely that would help a lot.
>>
>> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>>
>> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>>
>> Is that correct? How different this going to be from PCE?
>>
>
>
> Pranjal, all,
>
> My two cents. Apologies if this is well known, I am not sure I fully
> grasped your question...
>
> IMHO, the idea of separating LSA flooding from CSPF computation has
> indeed been a current topic for a while, and when it is tied to the idea
> of offloading the CSPF computation to a dedicated centralized server
> (for example a PCE),  I would guess/say that this is usually scoped and
> applies to the case when one formally decouples the control plane from
> the data plane (thus constructing a LSDB and establishing adjacencies in
> the control plane network and also constructing a separated Traffic
> Engineering Database or TED, which is described via opaque LSAs).
>
> In this particular scenario, the CSPF refers to /applies to the
> dataplane only (as is done in GMPLS/PCE), and one still needs SPF for
> the addresses in the DCN. In other words, OSPF-TE is used to disseminate
> data plane (TE) link/node attribute changes (in addition to what OSFPv2
> already does) and for this establishes routing adjacencies and the PCE
> performs CSPF on the TED, which can be a completely different topology.
>
> However, regarding your question "how different from a PCE", I would say
> these are complementary : first a) the PCE architecture does not specify
> how it obtains the Traffic Engineering Database (TED) to construct the
> directed graph on which it operates (i.e., performs CSPF, usually upon
> request); the PCE does not usually care much about the control plane
> topology and, b) what you refer to "push to each router" and "inject
> entries into the RIB" is completely orthogonal to a PCE.
>
> For a), and as stated previously in the list, a common way is to be a
> passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to
> contact a topology server or NMS that has the current topology  (TED).
> In other words, a PCE is a decoupled functional component and the
> protocol (PCEP) only specifies the interface to request path
> computations. Even if one uses a PCE and a lightweight LSA flooding
> protocol, SPF still needs to be executed by nodes to "forward" control
> packets, usually using the uncontrained shortest IP route. For b) note
> that, as of now, there is no standard way by which a PCE can configure
> the dataplane by itself. By "configure the dataplane" one can mean to
> "trigger" the establishment of LSPs via RSVP-TE signaling, or configure
> the cross-connects via OpenFlow or to set up state in the datapath
> (could even be configuring the RIB), somehow.
>
> Recently, Ed has started work in stateful PCE, and it is possible that
> in the future it will have the capability to "command" the establishment
> of connections.
>
> In summary, I see the (generic) relationship between PCE and IRS in two
> main ways:
>
> * As a means to communicate / obtain the TED, typically constructed via
> OSPF-TE opaque LSAs. This would be an alternative to existing methods /
> current practice. Another main driver for this is the Hierarchical PCE
> (H-PCE) in case a parent PCE needs to know about an (aggregated)
> topology within a (child) domain, since parent / child PCEs may not be
> in the same IGP area.
> In this sense, and as stated in the list, for this, other considered
> solutions are BGPLS / north bound interfaces or to use notify (PCNtf)
> messages wrapping TE LSAs for this.
>
> * As a means to define data plane state (much like OpenFlow) once a Path
> has been computed.
>
> Imho these are two areas which the PCE architecture and protocol do not
> currently cover and in which an architecture such as IRS could be helpful.
>
> Hope this helps (a little!)
>
> Best regards
>
> Ramon
>
> --
> Ramon Casellas, Ph.D.
> Research Associate - Optical Networking Area --http://wikiona.cttc.es
> CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
> Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
> Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01
>
>
>

Date: Thu, 16 Aug 2012 21:48:02 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

That's a good question and we need to figure out the appropriate
boundaries for what constitutes the "Routing System".

For instance, I'm not sure that it makes sense to be able to change
the admin-status of a physical interface - but if one thinks about a
use-case around creating an overlay network, I can see the need to
create the tunnel, turn it into an interface, turn on OSPF across it,
and then enable the interface.

This is where I think that having clear motivating use-cases will help
us define the borders for the sub-interfaces more clearly.

Alia

On Thu, Aug 16, 2012 at 2:56 PM, Shah, Himanshu <[email-masked]> wrote:
> I used ifMIB info to refer to ifTable specific information for each interface as ifSpeed, ifOperStatus, ifAdminStatus, ifMTU, etc etc
> Most of them are read but some are read/write - such as admin-status.
> So for example, would IRS interface provide changing admin-status of an interface on a node?
>
> /himanshu

==snip=

Date: Thu, 16 Aug 2012 21:44:47 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I'm not entirely clear on the model or question you are asking.  An
application could learn topology via IRS to the appropriate IRS
agents, do CSPF computations, and support a signaling/CSPF-like
sub-interface (if we define such for IRS) as an IRS agent.  Another
application could query the first for the CSPF results and then use
IRS to trigger signaling on the appropriate device.

I'm not sure if it makes sense to have an IRS sub-interface that
requests CSPF computation, but it might come as part of an RSVP
sub-interface to trigger signaling.  We'll have to see about
use-cases.

I don't see a strong motivation to duplicate existing work.

Alia

On Thu, Aug 16, 2012 at 2:46 PM, Shah, Himanshu <[email-masked]> wrote:
> I was wondering if PCE and IRS could have overlapping functionality.
>
> Meaning, can an IRS interface user at both ends (node and controller) be a non-PCE entity and perform
> the same service as what PCE does?
>
> It seems like you are saying that could work co-operatively...
>
> Thanks,
> himanshu

=snip=

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Ramon Casellas <[email-masked]>
Date: Fri, 17 Aug 2012 05:11:14 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Thanks for detailed explanation. My question on LSA flooding was not in the context of PCE or CSPF/TE-DB but on the issue of "regular/unconstrained" SPF computation in IGPs. The dynamics between a) CSPF on TE-DB and b) regular SPF on each link state change in a network are much different. My concern was primarily on b) - I don't see what it achieves and in fact may degrade FIB convergence performance abysmally. 

As Alia has clarified, we haven't heard of any clear, realistic use case of b). I agree with you that missing pieces in PCE may be addressed thru IRS. 

Thanks,
Pranjal

-----Original Message-----
From: Ramon Casellas [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 9:58 AM
To: Dutta, Pranjal K (Pranjal)
Cc: Alia Atlas; [email-masked]
Subject: Re: [irs-discuss] IRS comments

On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>

Pranjal, all,

My two cents. Apologies if this is well known, I am not sure I fully 
grasped your question...

IMHO, the idea of separating LSA flooding from CSPF computation has 
indeed been a current topic for a while, and when it is tied to the idea 
of offloading the CSPF computation to a dedicated centralized server 
(for example a PCE),  I would guess/say that this is usually scoped and 
applies to the case when one formally decouples the control plane from 
the data plane (thus constructing a LSDB and establishing adjacencies in 
the control plane network and also constructing a separated Traffic 
Engineering Database or TED, which is described via opaque LSAs).

In this particular scenario, the CSPF refers to /applies to the 
dataplane only (as is done in GMPLS/PCE), and one still needs SPF for 
the addresses in the DCN. In other words, OSPF-TE is used to disseminate 
data plane (TE) link/node attribute changes (in addition to what OSFPv2 
already does) and for this establishes routing adjacencies and the PCE 
performs CSPF on the TED, which can be a completely different topology.

However, regarding your question "how different from a PCE", I would say 
these are complementary : first a) the PCE architecture does not specify 
how it obtains the Traffic Engineering Database (TED) to construct the 
directed graph on which it operates (i.e., performs CSPF, usually upon 
request); the PCE does not usually care much about the control plane 
topology and, b) what you refer to "push to each router" and "inject 
entries into the RIB" is completely orthogonal to a PCE.

For a), and as stated previously in the list, a common way is to be a 
passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to 
contact a topology server or NMS that has the current topology  (TED). 
In other words, a PCE is a decoupled functional component and the 
protocol (PCEP) only specifies the interface to request path 
computations. Even if one uses a PCE and a lightweight LSA flooding 
protocol, SPF still needs to be executed by nodes to "forward" control 
packets, usually using the uncontrained shortest IP route. For b) note 
that, as of now, there is no standard way by which a PCE can configure 
the dataplane by itself. By "configure the dataplane" one can mean to 
"trigger" the establishment of LSPs via RSVP-TE signaling, or configure 
the cross-connects via OpenFlow or to set up state in the datapath 
(could even be configuring the RIB), somehow.

Recently, Ed has started work in stateful PCE, and it is possible that 
in the future it will have the capability to "command" the establishment 
of connections.

In summary, I see the (generic) relationship between PCE and IRS in two 
main ways:

* As a means to communicate / obtain the TED, typically constructed via 
OSPF-TE opaque LSAs. This would be an alternative to existing methods / 
current practice. Another main driver for this is the Hierarchical PCE 
(H-PCE) in case a parent PCE needs to know about an (aggregated) 
topology within a (child) domain, since parent / child PCEs may not be 
in the same IGP area.
In this sense, and as stated in the list, for this, other considered 
solutions are BGPLS / north bound interfaces or to use notify (PCNtf) 
messages wrapping TE LSAs for this.

* As a means to define data plane state (much like OpenFlow) once a Path 
has been computed.

Imho these are two areas which the PCE architecture and protocol do not 
currently cover and in which an architecture such as IRS could be helpful.

Hope this helps (a little!)

Best regards

Ramon

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area --http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01

From: "Shah, Himanshu" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 14:56:37 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I used ifMIB info to refer to ifTable specific information for each interface as ifSpeed, ifOperStatus, ifAdminStatus, ifMTU, etc etc
Most of them are read but some are read/write - such as admin-status.
So for example, would IRS interface provide changing admin-status of an interface on a node?

/himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 12:23 PM
To: Shah, Himanshu
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

ACLs as in for BGP policy or as in policy-based-routing/firewalls?
Both would be likely needed.

ifMIB info?  I'm not sure what aspects you are poking at.  In terms of reading information for the topology export, yes...  In terms of writing state, I don't think so...

Alia

On Thu, Aug 16, 2012 at 10:42 AM, Shah, Himanshu <[email-masked]> wrote:
> This is precisely the answer I was looking for.
> It's a domain issue. This is how IRS distinguishes itself from 
> OpenFlow/ForCES/GSMP etc etc
>
> Understand the reasoning but was hoping that IRS would provide one 
> uniform interface - top to bottom, so implementers do not have to deal with supporting multiple utilities.
>
> What about ACL (Access Control List), ifMIB specific info etc. (trying 
> to get sense on the lowest layer that IRS will cover)
>
> Thanks,
> himanshu
>
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 10:57 PM
> To: Shah, Himanshu
> Cc: UTTARO, JAMES; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> What is the benefit of allowing access to the FIB vs. the associated complexity?
> If something wants to inject state directly into the forwarding plane, isn't that what ForCES or OpenFlow is for?
>
> Why get into low-level assembly when we've got a C-equiv?  (Still not a higher level language that apps might speak with associated abstractions, but closer).
>
> Alia

---snip---

From: "Shah, Himanshu" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 14:46:32 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I was wondering if PCE and IRS could have overlapping functionality.

Meaning, can an IRS interface user at both ends (node and controller) be a non-PCE entity and perform
the same service as what PCE does?

It seems like you are saying that could work co-operatively...

Thanks,
himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 12:19 PM
To: Shah, Himanshu
Cc: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Can you be more specific on the "what about PCE which offloads CSP"?

An IRS agent could be co-located with a PCE and support the appropriate sub-interface.  A PCE could use IRS to talk to an IRS agent on a device to learn topology.

Alia

On Thu, Aug 16, 2012 at 10:41 AM, Shah, Himanshu <[email-masked]> wrote:
> I do agree but was asking specifically to understand the difference between IRS and other utilities like OpenFlow, GSMP, etc.
> and what is in IRS scope.   IRS just provides the interface. If it were to cover FIB, the "controller" would not add FIB and RIB in
> the same node/network.
>
> Anyway, curious about IRS boundaries - what about PCE which offloads CSPF?
>
> Thanks,
> Himanshu
>
> -----Original Message-----
> From: Dutta, Pranjal K (Pranjal)
> [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 12:30 AM
> To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas
> Cc: [email-masked]
> Subject: RE: [irs-discuss] IRS comments
>
> I think I may be missing something basic here. If access to both RIB (injecting route) and FIB (injecting h/w entry??) are allowed then what decides the consistency between RIB and FIB? I think at this moment we shouldn't go below the RIB.
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 7:02 PM
> To: UTTARO, JAMES; Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> Yes I agree. I meant precedence value (pardon the use of wrong terminology).
> Each entity that injects route to routing table has an associated precedence value..
>
> Anyway, I am more curious to know why not allow access to FIB..
>
> /himanshu
>
> -----Original Message-----
> From: UTTARO, JAMES [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 7:50 PM
> To: Shah, Himanshu; Alia Atlas
> Cc: [email-masked]
> Subject: RE: [irs-discuss] IRS comments
>
> Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..
>
> Jim Uttaro
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 6:57 PM
> To: Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> OK - So that I am clear...
>
> IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.
>
> The next step is then programming the FIB on the line card (if applicable).
>
> Would make sense for IRS to not provide interface to the FIB on the second step.
> But you are saying that it would also not provide interface to FIB of the first step.
>
> Is that correct?
>
> /himanshu
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 6:05 PM
> To: Shah, Himanshu
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I don't see IRS going below the RIB layer to FIB.
>
> Alia
>
> On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
>> I will let Ed clarify on what he means by "controller" .
>>
>>
>>
>> But here is my view of "application", "controller", "use-case" etc
>> etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc.
>> to instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network "Controller(s)"  knows current state of network
>> infrastructure and (to be decided how much it) controls member
>> network nodes using IRS.
>>
>> The "use case" here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface) ->
>> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP
>> policies, all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require
>> accessibility to -
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view - not
>> sure if this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Thanks.  Can you also give us what you mean by "controller".
>>
>>
>>
>> Olen
>>
>>
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 1:24 PM
>> To: Alia Atlas
>> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> s/wg/pre-BOF proto-wg :P/g
>>
>> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having
>> +gone a few
>> rounds with folks on this one in other forums, I'll point out that
>> what most people mean by application (myself included) is some set of
>> control software (a scheduler, a path optimizer etc)  that provides
>> instructions to the controller, which are in turn translated to the appropriate PDUs.
>>
>>
>>
>> Having 'end user' applications request/make changes to forwarding
>> state without an intermediate broker/aggregator acting on their
>> behalf sounds like a recipe for disaster for operational networks,
>> or, as is more likely, a quick hike to the protocol grave yard
>> (followed by a long grave-side party
>> :P) for the wg.
>>
>>
>>
>> my 2c.
>>
>>
>>
>> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to
>> routing devices via IRS.  I can see that going through an
>> intermediary.  The IRS abstractions are unlikely to be as high-level
>> as user-land applications would want and the security and policy
>> issues would get exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake)
>> <[email-masked]>
>> wrote:
>>> As another newbie to this, I have some questions about "application
>>> vendors."
>>>
>>> Who is the target audience here ?   That will determine what functionality
>>> and abstraction of the network we need to expose to that "application."
>>>
>>> This presently appears to be a little confused - at least in my mind.
>>> The draft talks very much as if the application we are addressing is
>>> an OSS/BSS system, essentially provisioning from the domain owner.
>>>
>>> However, linking this to the wider goals of SDN as voiced by
>>> customers/users at the first Open Network Summit, there appears to
>>> be a desire for cross-domain and user-land application integration.
>>>
>>> At this level - as an example giving a content cache the ability to
>>> ensure delivery of an HD video to an end user - the application will
>>> not be interested in the underlying topology of the network; it will
>>> need to know that application X can be delivered with parameters Y between reading from
>>> the content store to delivery to the user's browser.   How the stream
>>> traverses the infrastructure is immaterial.
>>>
>>> Are we intending that IRS satisfies BOTH these requirements (i.e.
>>> for ALL applications ?), or should we be more prescriptive about
>>> which application space we are addressing ?
>>>
>>> Thanks
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]]
>>> On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 7:23 AM
>>> To: Olen Stokes
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> I have not specifically heard from application vendors about this.
>>> My current plan is that we focus on a Use-Cases draft and define
>>> within that some motivating use-cases that we agree are good first
>>> targets.  Those can drive which subset of functionality we focus on.
>>>
>>> More use-cases are, of course, quite welcome.  Posting them to the
>>> mailing list is a good first start.  Russ White is starting the
>>> general use-cases draft based on the three use-cases that he sent to the list.
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>>> <[email-masked]>
>>> wrote:
>>>> Are there applications vendors out there that already have specific
>>>> requirements for what this " subset of the data-models for sub-interfaces"
>>>> should be?
>>>>
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>>> To: Shah, Himanshu
>>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>>> Nadeau; Alia Atlas; Scott Whyte
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> Hi Himanshu,
>>>>
>>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>>> formed - I expect that we'll focus on a subset of the data-models
>>>> for sub-interfaces along with an associated protocol (whether that
>>>> is a new one or extending an existing one).
>>>>
>>>> Alia
>>>>
>>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>>> Newbie to this discussions list and have read only a last couple
>>>>> of mails, so pardon the repeat if somebody has already raised the
>>>>> following as a concern.
>>>>>
>>>>> I realize we are early in IRS architecture definition but one
>>>>> thing to keep in mind is the user experience.
>>>>> We need to make sure that exposed interface to
>>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>>> predictive action/response/events even when different
>>>>> implementations has varying capabilities.
>>>>>
>>>>> At the moment it seems like a wild wild west.
>>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>>> limited version..
>>>>>
>>>>> Thanks,
>>>>> himanshu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>>> To: Scott Whyte
>>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>>> [email-masked]
>>>>> Subject: Re: [irs-discuss] IRS comments
>>>>>
>>>>> ...snip...
>>>>>
>>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>>
>>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>>> gives good semantics and interactions.  Obviously,
>>>>>>> implementations may differ.
>>>>>>
>>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>>> operator to whatever precedence they want, I agree.  Its not
>>>>>> clear to me if various RIB implementations treat all proffered
>>>>>> routes the same, nor if they store the same meta-data with all protocol sources.
>>>>>> So there needs to be some way for the operator to leverage
>>>>>> exposed protocol-specific optimizations, without conflict from
>>>>>> the other routing processes, if they so desire.  OTOH if it can
>>>>>> all be done via static routes, it seems much simpler. :)
>>>>>
>>>>> Clearly the IRS sub-interface for the RIB needs to
>>>>> introduce/define the different precedences; my assumption is that
>>>>> it would be per route with a well-defined small set of meta-data.
>>>>> This is part of where having good use-cases will help us
>>>>> understand what behavior is necessary.  The static routes do seem like a simpler case to start with.
>>>>>
>>>>> Alia
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Thu, 16 Aug 2012 18:57:54 +0200
From: Ramon Casellas <[email-masked]>
Organization: CTTC
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

On 08/16/2012 06:14 PM, Dutta, Pranjal K (Pranjal) wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>

Pranjal, all,

My two cents. Apologies if this is well known, I am not sure I fully 
grasped your question...

IMHO, the idea of separating LSA flooding from CSPF computation has 
indeed been a current topic for a while, and when it is tied to the idea 
of offloading the CSPF computation to a dedicated centralized server 
(for example a PCE),  I would guess/say that this is usually scoped and 
applies to the case when one formally decouples the control plane from 
the data plane (thus constructing a LSDB and establishing adjacencies in 
the control plane network and also constructing a separated Traffic 
Engineering Database or TED, which is described via opaque LSAs).

In this particular scenario, the CSPF refers to /applies to the 
dataplane only (as is done in GMPLS/PCE), and one still needs SPF for 
the addresses in the DCN. In other words, OSPF-TE is used to disseminate 
data plane (TE) link/node attribute changes (in addition to what OSFPv2 
already does) and for this establishes routing adjacencies and the PCE 
performs CSPF on the TED, which can be a completely different topology.

However, regarding your question "how different from a PCE", I would say 
these are complementary : first a) the PCE architecture does not specify 
how it obtains the Traffic Engineering Database (TED) to construct the 
directed graph on which it operates (i.e., performs CSPF, usually upon 
request); the PCE does not usually care much about the control plane 
topology and, b) what you refer to "push to each router" and "inject 
entries into the RIB" is completely orthogonal to a PCE.

For a), and as stated previously in the list, a common way is to be a 
passive listener or to sniff LSAs with opaque (MPLS TE, area-wide) or to 
contact a topology server or NMS that has the current topology  (TED). 
In other words, a PCE is a decoupled functional component and the 
protocol (PCEP) only specifies the interface to request path 
computations. Even if one uses a PCE and a lightweight LSA flooding 
protocol, SPF still needs to be executed by nodes to "forward" control 
packets, usually using the uncontrained shortest IP route. For b) note 
that, as of now, there is no standard way by which a PCE can configure 
the dataplane by itself. By "configure the dataplane" one can mean to 
"trigger" the establishment of LSPs via RSVP-TE signaling, or configure 
the cross-connects via OpenFlow or to set up state in the datapath 
(could even be configuring the RIB), somehow.

Recently, Ed has started work in stateful PCE, and it is possible that 
in the future it will have the capability to "command" the establishment 
of connections.

In summary, I see the (generic) relationship between PCE and IRS in two 
main ways:

* As a means to communicate / obtain the TED, typically constructed via 
OSPF-TE opaque LSAs. This would be an alternative to existing methods / 
current practice. Another main driver for this is the Hierarchical PCE 
(H-PCE) in case a parent PCE needs to know about an (aggregated) 
topology within a (child) domain, since parent / child PCEs may not be 
in the same IGP area.
In this sense, and as stated in the list, for this, other considered 
solutions are BGPLS / north bound interfaces or to use notify (PCNtf) 
messages wrapping TE LSAs for this.

* As a means to define data plane state (much like OpenFlow) once a Path 
has been computed.

Imho these are two areas which the PCE architecture and protocol do not 
currently cover and in which an architecture such as IRS could be helpful.

Hope this helps (a little!)

Best regards

Ramon

-- 
Ramon Casellas, Ph.D.
Research Associate - Optical Networking Area --http://wikiona.cttc.es
CTTC - Centre Tecnològic de Telecomunicacions de Catalunya, PMT Ed B4
Av. Carl Friedrich Gauss, 7 - 08860 Castelldefels (Barcelona) - Spain
Tel.: +34 93 645 29 00 -- Fax. +34 93 645 29 01

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 22:09:53 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "UTTARO, JAMES" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Thanks for the clarification. Yes, that's why I was poking for use-cases first. 

Thanks,
Pranjal

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 9:35 AM
To: Dutta, Pranjal K (Pranjal)
Cc: Shah, Himanshu; UTTARO, JAMES; [email-masked]
Subject: Re: [irs-discuss] IRS comments

I haven't seen a good description of what is intended or desired by
moving the SPF functionality to a centralized location.  Clearly such
centralization can have a very bad impact on convergence - which is a
strong motivator for simultaneously computing fast-reroute
alternatives (with guaranteed coverage ala MRT) and installing both.

I don't see IRS as having a way of "turning off" the SPF computation
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia

On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
>
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>
> If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.
>
> But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persists longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.
>
> Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.
>
> I apologize if I misunderstood the intent.
>
> Thanks,
> Pranjal

---snip---

Date: Thu, 16 Aug 2012 12:34:43 -0400
From: Alia Atlas <[email-masked]>
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I haven't seen a good description of what is intended or desired by
moving the SPF functionality to a centralized location.  Clearly such
centralization can have a very bad impact on convergence - which is a
strong motivator for simultaneously computing fast-reroute
alternatives (with guaranteed coverage ala MRT) and installing both.

I don't see IRS as having a way of "turning off" the SPF computation
in the IGP; a different lobotomized IGP protocol/process would be
needed.

Alia

On Thu, Aug 16, 2012 at 12:14 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> "LSDB (I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)"
>
> I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
> precisely that would help a lot.
>
> Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.
>
> Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.
>
> Is that correct? How different this going to be from PCE?
>
> If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?
>
> The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.
>
> But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.
>
> Static route interface is good thing because it is a state that persists longer.
>
> IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.
>
> Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.
>
> I apologize if I misunderstood the intent.
>
> Thanks,
> Pranjal

---snip---

Date: Thu, 16 Aug 2012 12:23:25 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

ACLs as in for BGP policy or as in policy-based-routing/firewalls?
Both would be likely needed.

ifMIB info?  I'm not sure what aspects you are poking at.  In terms of
reading information for the topology export, yes...  In terms of
writing state, I don't think so...

Alia

On Thu, Aug 16, 2012 at 10:42 AM, Shah, Himanshu <[email-masked]> wrote:
> This is precisely the answer I was looking for.
> It's a domain issue. This is how IRS distinguishes itself from OpenFlow/ForCES/GSMP etc etc
>
> Understand the reasoning but was hoping that IRS would provide one uniform interface - top to bottom,
> so implementers do not have to deal with supporting multiple utilities.
>
> What about ACL (Access Control List), ifMIB specific info etc. (trying to get sense on the lowest layer that IRS will cover)
>
> Thanks,
> himanshu
>
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 10:57 PM
> To: Shah, Himanshu
> Cc: UTTARO, JAMES; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> What is the benefit of allowing access to the FIB vs. the associated complexity?
> If something wants to inject state directly into the forwarding plane, isn't that what ForCES or OpenFlow is for?
>
> Why get into low-level assembly when we've got a C-equiv?  (Still not a higher level language that apps might speak with associated abstractions, but closer).
>
> Alia

---snip---

Date: Thu, 16 Aug 2012 12:19:18 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "Dutta, Pranjal K \(Pranjal\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Can you be more specific on the "what about PCE which offloads CSP"?

An IRS agent could be co-located with a PCE and support the
appropriate sub-interface.  A PCE could use IRS to talk to an IRS
agent on a device to learn topology.

Alia

On Thu, Aug 16, 2012 at 10:41 AM, Shah, Himanshu <[email-masked]> wrote:
> I do agree but was asking specifically to understand the difference between IRS and other utilities like OpenFlow, GSMP, etc.
> and what is in IRS scope.   IRS just provides the interface. If it were to cover FIB, the "controller" would not add FIB and RIB in
> the same node/network.
>
> Anyway, curious about IRS boundaries - what about PCE which offloads CSPF?
>
> Thanks,
> Himanshu
>
> -----Original Message-----
> From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
> Sent: Thursday, August 16, 2012 12:30 AM
> To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas
> Cc: [email-masked]
> Subject: RE: [irs-discuss] IRS comments
>
> I think I may be missing something basic here. If access to both RIB (injecting route) and FIB (injecting h/w entry??) are allowed then what decides the consistency between RIB and FIB? I think at this moment we shouldn't go below the RIB.
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 7:02 PM
> To: UTTARO, JAMES; Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> Yes I agree. I meant precedence value (pardon the use of wrong terminology).
> Each entity that injects route to routing table has an associated precedence value..
>
> Anyway, I am more curious to know why not allow access to FIB..
>
> /himanshu
>
> -----Original Message-----
> From: UTTARO, JAMES [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 7:50 PM
> To: Shah, Himanshu; Alia Atlas
> Cc: [email-masked]
> Subject: RE: [irs-discuss] IRS comments
>
> Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..
>
> Jim Uttaro
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 6:57 PM
> To: Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> OK - So that I am clear...
>
> IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.
>
> The next step is then programming the FIB on the line card (if applicable).
>
> Would make sense for IRS to not provide interface to the FIB on the second step.
> But you are saying that it would also not provide interface to FIB of the first step.
>
> Is that correct?
>
> /himanshu
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 6:05 PM
> To: Shah, Himanshu
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I don't see IRS going below the RIB layer to FIB.
>
> Alia
>
> On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
>> I will let Ed clarify on what he means by "controller" .
>>
>>
>>
>> But here is my view of "application", "controller", "use-case" etc
>> etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc.
>> to instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network "Controller(s)"  knows current state of network
>> infrastructure and (to be decided how much it) controls member network
>> nodes using IRS.
>>
>> The "use case" here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface) ->
>> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP
>> policies, all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require
>> accessibility to -
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view - not
>> sure if this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Thanks.  Can you also give us what you mean by "controller".
>>
>>
>>
>> Olen
>>
>>
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 1:24 PM
>> To: Alia Atlas
>> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> s/wg/pre-BOF proto-wg :P/g
>>
>> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having gone
>> +a few
>> rounds with folks on this one in other forums, I'll point out that
>> what most people mean by application (myself included) is some set of
>> control software (a scheduler, a path optimizer etc)  that provides
>> instructions to the controller, which are in turn translated to the appropriate PDUs.
>>
>>
>>
>> Having 'end user' applications request/make changes to forwarding
>> state without an intermediate broker/aggregator acting on their behalf
>> sounds like a recipe for disaster for operational networks, or, as is
>> more likely, a quick hike to the protocol grave yard (followed by a
>> long grave-side party
>> :P) for the wg.
>>
>>
>>
>> my 2c.
>>
>>
>>
>> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to routing
>> devices via IRS.  I can see that going through an intermediary.  The
>> IRS abstractions are unlikely to be as high-level as user-land
>> applications would want and the security and policy issues would get
>> exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
>> wrote:
>>> As another newbie to this, I have some questions about "application
>>> vendors."
>>>
>>> Who is the target audience here ?   That will determine what functionality
>>> and abstraction of the network we need to expose to that "application."
>>>
>>> This presently appears to be a little confused - at least in my mind.
>>> The draft talks very much as if the application we are addressing is
>>> an OSS/BSS system, essentially provisioning from the domain owner.
>>>
>>> However, linking this to the wider goals of SDN as voiced by
>>> customers/users at the first Open Network Summit, there appears to be
>>> a desire for cross-domain and user-land application integration.
>>>
>>> At this level - as an example giving a content cache the ability to
>>> ensure delivery of an HD video to an end user - the application will
>>> not be interested in the underlying topology of the network; it will
>>> need to know that application X can be delivered with parameters Y between reading from
>>> the content store to delivery to the user's browser.   How the stream
>>> traverses the infrastructure is immaterial.
>>>
>>> Are we intending that IRS satisfies BOTH these requirements (i.e. for
>>> ALL applications ?), or should we be more prescriptive about which
>>> application space we are addressing ?
>>>
>>> Thanks
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]]
>>> On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 7:23 AM
>>> To: Olen Stokes
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> I have not specifically heard from application vendors about this.
>>> My current plan is that we focus on a Use-Cases draft and define
>>> within that some motivating use-cases that we agree are good first
>>> targets.  Those can drive which subset of functionality we focus on.
>>>
>>> More use-cases are, of course, quite welcome.  Posting them to the
>>> mailing list is a good first start.  Russ White is starting the
>>> general use-cases draft based on the three use-cases that he sent to the list.
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>>> <[email-masked]>
>>> wrote:
>>>> Are there applications vendors out there that already have specific
>>>> requirements for what this " subset of the data-models for sub-interfaces"
>>>> should be?
>>>>
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>>> To: Shah, Himanshu
>>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>>> Nadeau; Alia Atlas; Scott Whyte
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> Hi Himanshu,
>>>>
>>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>>> formed - I expect that we'll focus on a subset of the data-models
>>>> for sub-interfaces along with an associated protocol (whether that
>>>> is a new one or extending an existing one).
>>>>
>>>> Alia
>>>>
>>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>>> Newbie to this discussions list and have read only a last couple of
>>>>> mails, so pardon the repeat if somebody has already raised the
>>>>> following as a concern.
>>>>>
>>>>> I realize we are early in IRS architecture definition but one thing
>>>>> to keep in mind is the user experience.
>>>>> We need to make sure that exposed interface to
>>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>>> predictive action/response/events even when different
>>>>> implementations has varying capabilities.
>>>>>
>>>>> At the moment it seems like a wild wild west.
>>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>>> limited version..
>>>>>
>>>>> Thanks,
>>>>> himanshu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>>> To: Scott Whyte
>>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>>> [email-masked]
>>>>> Subject: Re: [irs-discuss] IRS comments
>>>>>
>>>>> ...snip...
>>>>>
>>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>>
>>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>>> gives good semantics and interactions.  Obviously,
>>>>>>> implementations may differ.
>>>>>>
>>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>>> to me if various RIB implementations treat all proffered routes
>>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>>> So there needs to be some way for the operator to leverage exposed
>>>>>> protocol-specific optimizations, without conflict from the other
>>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>>> via static routes, it seems much simpler. :)
>>>>>
>>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>>>>> the different precedences; my assumption is that it would be per
>>>>> route with a well-defined small set of meta-data.  This is part of
>>>>> where having good use-cases will help us understand what behavior
>>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>>
>>>>> Alia
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 21:44:14 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

"LSDB (I saw an email which talks about reducing IGP to link
> distribution protocol and running SPF in centralized network
> controller)"

I have seen discussions in the past on this and in fact I didn't get precisely what is meant. If anybody in the list could brief very
precisely that would help a lot.

Here is my understanding - the routers would do LSA/LSP flooding for OSPF/ISIS as it is done today. So routers would build neighboring relationship/adjacencies to participate in flooding and each router builds its LSDB.

Then the IRS "application" would track LSDB changes and pull up the "diffs" from each router (thru "controller") whenever there is a change. The application would compute SPF on behalf of each router (LSDB). The result of the compute would be pushed by application to each Router (thru controller) and inject entries into RIB.

Is that correct? How different this going to be from PCE?

If this is correct then perhaps we would like to ask what are the scalability numbers in LSDB we are talking about?

The "application" would be running in a high performance server and so SPF compute there is not an issue and perhaps it is good way to synchronize FIB update (to a certain extent) to avoid u-loops etc.

But when we are managing all routers in the purview of the application, the computing power in each router is not uniform. To be realistic, I have some concerns on how much "real-timeness" we could achieve between application and controllers on such proposals, esp. when scaling numbers are high. This leads to higher time lag on inconsistency between application SPF compute and FIB update. It's almost like the classic "slow peering" issues with TCP like protocols - the high performance peer is slowed down by low performance peer.

Static route interface is good thing because it is a state that persists longer.

IGPs may be deployed in very dynamic environments where tight coupling is desirable between SPF compute and FIB update. In scaled environments the issue is less about SPF compute time and is more about synchronizing the FIB.

Running on-demand CSPF by IRS application may be fine because of persistency of RSVP-TE tunnels in dynamic environments.

I apologize if I misunderstood the intent.

Thanks,
Pranjal

-----Original Message-----
From: Shah, Himanshu [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 7:41 AM
To: Dutta, Pranjal K (Pranjal); UTTARO, JAMES; Alia Atlas
Cc: [email-masked]
Subject: RE: [irs-discuss] IRS comments

I do agree but was asking specifically to understand the difference between IRS and other utilities like OpenFlow, GSMP, etc.
and what is in IRS scope.   IRS just provides the interface. If it were to cover FIB, the "controller" would not add FIB and RIB in
the same node/network.

Anyway, curious about IRS boundaries - what about PCE which offloads CSPF?

Thanks,
Himanshu

-----Original Message-----
From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 12:30 AM
To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas
Cc: [email-masked]
Subject: RE: [irs-discuss] IRS comments

I think I may be missing something basic here. If access to both RIB (injecting route) and FIB (injecting h/w entry??) are allowed then what decides the consistency between RIB and FIB? I think at this moment we shouldn't go below the RIB.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 7:02 PM
To: UTTARO, JAMES; Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

Yes I agree. I meant precedence value (pardon the use of wrong terminology).
Each entity that injects route to routing table has an associated precedence value..

Anyway, I am more curious to know why not allow access to FIB..

/himanshu

-----Original Message-----
From: UTTARO, JAMES [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 7:50 PM
To: Shah, Himanshu; Alia Atlas
Cc: [email-masked]
Subject: RE: [irs-discuss] IRS comments

Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 6:57 PM
To: Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

OK - So that I am clear...

IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.

The next step is then programming the FIB on the line card (if applicable).

Would make sense for IRS to not provide interface to the FIB on the second step.
But you are saying that it would also not provide interface to FIB of the first step.

Is that correct?

/himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 6:05 PM
To: Shah, Himanshu
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I don't see IRS going below the RIB layer to FIB.

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> I will let Ed clarify on what he means by "controller" .
>
>
>
> But here is my view of "application", "controller", "use-case" etc
> etc,
>
>
>
> When an XaaS processes a request it takes into consideration of
> availability of the CPU, memory, application data, cost of power, etc.
> to instantiate a VM on some host machine.
>
> One additional resource taken into consideration is the availability
> and/or requirement of the network connectivity between the resources
>
> such as VM, application data, requester, etc.
>
>
>
> The provider of XaaS thingy is the application server.
>
> (Centralized) Network "Controller(s)"  knows current state of network
> infrastructure and (to be decided how much it) controls member network
> nodes using IRS.
>
> The "use case" here is to be able to dynamically create L2/L2.5/L3
> connectivity with specific TE characteristics between the (perhaps
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> As we heard at IETF, IRS has tentacles in network nodes from BGP
> policies, all the way down to FIBs/LFIBs/ACL.
>
>
>
> So we need use cases for which applications would require
> accessibility to -
>
> BGP Policies
>
> RIB
>
> LSDB ( I saw an email which talks about reducing IGP to link
> distribution protocol and running SPF in centralized network
> controller)
>
> LIB
>
> FIB
>
> ACL (this is perhaps obvious)
>
> Etc etc
>
>
>
> I broad brushed and simplified a lot here to express my view - not
> sure if this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 1:30 PM
> To: Edward Crabbe; Alia Atlas
> Cc: David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> Thanks.  Can you also give us what you mean by "controller".
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone
> +a few
> rounds with folks on this one in other forums, I'll point out that
> what most people mean by application (myself included) is some set of
> control software (a scheduler, a path optimizer etc)  that provides
> instructions to the controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding
> state without an intermediate broker/aggregator acting on their behalf
> sounds like a recipe for disaster for operational networks, or, as is
> more likely, a quick hike to the protocol grave yard (followed by a
> long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.
>> The draft talks very much as if the application we are addressing is
>> an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by
>> customers/users at the first Open Network Summit, there appears to be
>> a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to
>> ensure delivery of an HD video to an end user - the application will
>> not be interested in the underlying topology of the network; it will
>> need to know that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for
>> ALL applications ?), or should we be more prescriptive about which
>> application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define
>> within that some motivating use-cases that we agree are good first
>> targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the
>> mailing list is a good first start.  Russ White is starting the
>> general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>> <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models
>>> for sub-interfaces along with an associated protocol (whether that
>>> is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of
>>>> mails, so pardon the repeat if somebody has already raised the
>>>> following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing
>>>> to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>> predictive action/response/events even when different
>>>> implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>> limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>> gives good semantics and interactions.  Obviously,
>>>>>> implementations may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>> to me if various RIB implementations treat all proffered routes
>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed
>>>>> protocol-specific optimizations, without conflict from the other
>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>>>> the different precedences; my assumption is that it would be per
>>>> route with a well-defined small set of meta-data.  This is part of
>>>> where having good use-cases will help us understand what behavior
>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Shah, Himanshu" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 10:42:48 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

This is precisely the answer I was looking for.
It's a domain issue. This is how IRS distinguishes itself from OpenFlow/ForCES/GSMP etc etc

Understand the reasoning but was hoping that IRS would provide one uniform interface - top to bottom,
so implementers do not have to deal with supporting multiple utilities.

What about ACL (Access Control List), ifMIB specific info etc. (trying to get sense on the lowest layer that IRS will cover)

Thanks,
himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 10:57 PM
To: Shah, Himanshu
Cc: UTTARO, JAMES; [email-masked]
Subject: Re: [irs-discuss] IRS comments

What is the benefit of allowing access to the FIB vs. the associated complexity?
If something wants to inject state directly into the forwarding plane, isn't that what ForCES or OpenFlow is for?

Why get into low-level assembly when we've got a C-equiv?  (Still not a higher level language that apps might speak with associated abstractions, but closer).

Alia

On Wed, Aug 15, 2012 at 10:01 PM, Shah, Himanshu <[email-masked]> wrote:
> Yes I agree. I meant precedence value (pardon the use of wrong terminology).
> Each entity that injects route to routing table has an associated precedence value..
>
> Anyway, I am more curious to know why not allow access to FIB..
>
> /himanshu
>
> -----Original Message-----
> From: UTTARO, JAMES [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 7:50 PM
> To: Shah, Himanshu; Alia Atlas
> Cc: [email-masked]
> Subject: RE: [irs-discuss] IRS comments
>
> Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..
>
> Jim Uttaro
>
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 6:57 PM
> To: Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> OK - So that I am clear...
>
> IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.
>
> The next step is then programming the FIB on the line card (if applicable).
>
> Would make sense for IRS to not provide interface to the FIB on the second step.
> But you are saying that it would also not provide interface to FIB of the first step.
>
> Is that correct?
>
> /himanshu
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 6:05 PM
> To: Shah, Himanshu
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I don't see IRS going below the RIB layer to FIB.
>
> Alia
>
> On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
>> I will let Ed clarify on what he means by "controller" .
>>
>>
>>
>> But here is my view of "application", "controller", "use-case" etc
>> etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc.
>> to instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network "Controller(s)"  knows current state of network
>> infrastructure and (to be decided how much it) controls member
>> network nodes using IRS.
>>
>> The "use case" here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface) ->
>> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP
>> policies, all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require
>> accessibility to -
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view - not
>> sure if this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Thanks.  Can you also give us what you mean by "controller".
>>
>>
>>
>> Olen
>>
>>
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 1:24 PM
>> To: Alia Atlas
>> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> s/wg/pre-BOF proto-wg :P/g
>>
>> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having
>> +gone a few
>> rounds with folks on this one in other forums, I'll point out that
>> what most people mean by application (myself included) is some set of
>> control software (a scheduler, a path optimizer etc)  that provides
>> instructions to the controller, which are in turn translated to the appropriate PDUs.
>>
>>
>>
>> Having 'end user' applications request/make changes to forwarding
>> state without an intermediate broker/aggregator acting on their
>> behalf sounds like a recipe for disaster for operational networks,
>> or, as is more likely, a quick hike to the protocol grave yard
>> (followed by a long grave-side party
>> :P) for the wg.
>>
>>
>>
>> my 2c.
>>
>>
>>
>> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to
>> routing devices via IRS.  I can see that going through an
>> intermediary.  The IRS abstractions are unlikely to be as high-level
>> as user-land applications would want and the security and policy
>> issues would get exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake)
>> <[email-masked]>
>> wrote:
>>> As another newbie to this, I have some questions about "application
>>> vendors."
>>>
>>> Who is the target audience here ?   That will determine what functionality
>>> and abstraction of the network we need to expose to that "application."
>>>
>>> This presently appears to be a little confused - at least in my mind.
>>> The draft talks very much as if the application we are addressing is
>>> an OSS/BSS system, essentially provisioning from the domain owner.
>>>
>>> However, linking this to the wider goals of SDN as voiced by
>>> customers/users at the first Open Network Summit, there appears to
>>> be a desire for cross-domain and user-land application integration.
>>>
>>> At this level - as an example giving a content cache the ability to
>>> ensure delivery of an HD video to an end user - the application will
>>> not be interested in the underlying topology of the network; it will
>>> need to know that application X can be delivered with parameters Y between reading from
>>> the content store to delivery to the user's browser.   How the stream
>>> traverses the infrastructure is immaterial.
>>>
>>> Are we intending that IRS satisfies BOTH these requirements (i.e.
>>> for ALL applications ?), or should we be more prescriptive about
>>> which application space we are addressing ?
>>>
>>> Thanks
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]]
>>> On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 7:23 AM
>>> To: Olen Stokes
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> I have not specifically heard from application vendors about this.
>>> My current plan is that we focus on a Use-Cases draft and define
>>> within that some motivating use-cases that we agree are good first
>>> targets.  Those can drive which subset of functionality we focus on.
>>>
>>> More use-cases are, of course, quite welcome.  Posting them to the
>>> mailing list is a good first start.  Russ White is starting the
>>> general use-cases draft based on the three use-cases that he sent to the list.
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>>> <[email-masked]>
>>> wrote:
>>>> Are there applications vendors out there that already have specific
>>>> requirements for what this " subset of the data-models for sub-interfaces"
>>>> should be?
>>>>
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>>> To: Shah, Himanshu
>>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>>> Nadeau; Alia Atlas; Scott Whyte
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> Hi Himanshu,
>>>>
>>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>>> formed - I expect that we'll focus on a subset of the data-models
>>>> for sub-interfaces along with an associated protocol (whether that
>>>> is a new one or extending an existing one).
>>>>
>>>> Alia
>>>>
>>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>>> Newbie to this discussions list and have read only a last couple
>>>>> of mails, so pardon the repeat if somebody has already raised the
>>>>> following as a concern.
>>>>>
>>>>> I realize we are early in IRS architecture definition but one
>>>>> thing to keep in mind is the user experience.
>>>>> We need to make sure that exposed interface to
>>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>>> predictive action/response/events even when different
>>>>> implementations has varying capabilities.
>>>>>
>>>>> At the moment it seems like a wild wild west.
>>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>>> limited version..
>>>>>
>>>>> Thanks,
>>>>> himanshu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>>> To: Scott Whyte
>>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>>> [email-masked]
>>>>> Subject: Re: [irs-discuss] IRS comments
>>>>>
>>>>> ...snip...
>>>>>
>>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>>
>>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>>> gives good semantics and interactions.  Obviously,
>>>>>>> implementations may differ.
>>>>>>
>>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>>> operator to whatever precedence they want, I agree.  Its not
>>>>>> clear to me if various RIB implementations treat all proffered
>>>>>> routes the same, nor if they store the same meta-data with all protocol sources.
>>>>>> So there needs to be some way for the operator to leverage
>>>>>> exposed protocol-specific optimizations, without conflict from
>>>>>> the other routing processes, if they so desire.  OTOH if it can
>>>>>> all be done via static routes, it seems much simpler. :)
>>>>>
>>>>> Clearly the IRS sub-interface for the RIB needs to
>>>>> introduce/define the different precedences; my assumption is that
>>>>> it would be per route with a well-defined small set of meta-data.
>>>>> This is part of where having good use-cases will help us
>>>>> understand what behavior is necessary.  The static routes do seem like a simpler case to start with.
>>>>>
>>>>> Alia
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Shah, Himanshu" <[email-masked]>
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 10:41:06 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I do agree but was asking specifically to understand the difference between IRS and other utilities like OpenFlow, GSMP, etc.
and what is in IRS scope.   IRS just provides the interface. If it were to cover FIB, the "controller" would not add FIB and RIB in
the same node/network.

Anyway, curious about IRS boundaries - what about PCE which offloads CSPF?

Thanks,
Himanshu

-----Original Message-----
From: Dutta, Pranjal K (Pranjal) [mailto:[email-masked]]
Sent: Thursday, August 16, 2012 12:30 AM
To: Shah, Himanshu; UTTARO, JAMES; Alia Atlas
Cc: [email-masked]
Subject: RE: [irs-discuss] IRS comments

I think I may be missing something basic here. If access to both RIB (injecting route) and FIB (injecting h/w entry??) are allowed then what decides the consistency between RIB and FIB? I think at this moment we shouldn't go below the RIB.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 7:02 PM
To: UTTARO, JAMES; Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

Yes I agree. I meant precedence value (pardon the use of wrong terminology).
Each entity that injects route to routing table has an associated precedence value..

Anyway, I am more curious to know why not allow access to FIB..

/himanshu

-----Original Message-----
From: UTTARO, JAMES [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 7:50 PM
To: Shah, Himanshu; Alia Atlas
Cc: [email-masked]
Subject: RE: [irs-discuss] IRS comments

Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 6:57 PM
To: Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

OK - So that I am clear...

IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.

The next step is then programming the FIB on the line card (if applicable).

Would make sense for IRS to not provide interface to the FIB on the second step.
But you are saying that it would also not provide interface to FIB of the first step.

Is that correct?

/himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 6:05 PM
To: Shah, Himanshu
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I don't see IRS going below the RIB layer to FIB.

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> I will let Ed clarify on what he means by "controller" .
>
>
>
> But here is my view of "application", "controller", "use-case" etc
> etc,
>
>
>
> When an XaaS processes a request it takes into consideration of
> availability of the CPU, memory, application data, cost of power, etc.
> to instantiate a VM on some host machine.
>
> One additional resource taken into consideration is the availability
> and/or requirement of the network connectivity between the resources
>
> such as VM, application data, requester, etc.
>
>
>
> The provider of XaaS thingy is the application server.
>
> (Centralized) Network "Controller(s)"  knows current state of network
> infrastructure and (to be decided how much it) controls member network
> nodes using IRS.
>
> The "use case" here is to be able to dynamically create L2/L2.5/L3
> connectivity with specific TE characteristics between the (perhaps
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> As we heard at IETF, IRS has tentacles in network nodes from BGP
> policies, all the way down to FIBs/LFIBs/ACL.
>
>
>
> So we need use cases for which applications would require
> accessibility to -
>
> BGP Policies
>
> RIB
>
> LSDB ( I saw an email which talks about reducing IGP to link
> distribution protocol and running SPF in centralized network
> controller)
>
> LIB
>
> FIB
>
> ACL (this is perhaps obvious)
>
> Etc etc
>
>
>
> I broad brushed and simplified a lot here to express my view - not
> sure if this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 1:30 PM
> To: Edward Crabbe; Alia Atlas
> Cc: David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> Thanks.  Can you also give us what you mean by "controller".
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone
> +a few
> rounds with folks on this one in other forums, I'll point out that
> what most people mean by application (myself included) is some set of
> control software (a scheduler, a path optimizer etc)  that provides
> instructions to the controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding
> state without an intermediate broker/aggregator acting on their behalf
> sounds like a recipe for disaster for operational networks, or, as is
> more likely, a quick hike to the protocol grave yard (followed by a
> long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.
>> The draft talks very much as if the application we are addressing is
>> an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by
>> customers/users at the first Open Network Summit, there appears to be
>> a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to
>> ensure delivery of an HD video to an end user - the application will
>> not be interested in the underlying topology of the network; it will
>> need to know that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for
>> ALL applications ?), or should we be more prescriptive about which
>> application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define
>> within that some motivating use-cases that we agree are good first
>> targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the
>> mailing list is a good first start.  Russ White is starting the
>> general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>> <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models
>>> for sub-interfaces along with an associated protocol (whether that
>>> is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of
>>>> mails, so pardon the repeat if somebody has already raised the
>>>> following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing
>>>> to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>> predictive action/response/events even when different
>>>> implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>> limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>> gives good semantics and interactions.  Obviously,
>>>>>> implementations may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>> to me if various RIB implementations treat all proffered routes
>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed
>>>>> protocol-specific optimizations, without conflict from the other
>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>>>> the different precedences; my assumption is that it would be per
>>>> route with a well-defined small set of meta-data.  This is part of
>>>> where having good use-cases will help us understand what behavior
>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>, "UTTARO, JAMES" <[email-masked]>, Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 10:00:19 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I think I may be missing something basic here. If access to both RIB (injecting route) and FIB (injecting h/w entry??) are allowed then what decides the consistency between RIB and FIB? I think at this moment we shouldn't go below the RIB.

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 7:02 PM
To: UTTARO, JAMES; Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

Yes I agree. I meant precedence value (pardon the use of wrong terminology). 
Each entity that injects route to routing table has an associated precedence value..

Anyway, I am more curious to know why not allow access to FIB..

/himanshu

-----Original Message-----
From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 7:50 PM
To: Shah, Himanshu; Alia Atlas
Cc: [email-masked]
Subject: RE: [irs-discuss] IRS comments

Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 6:57 PM
To: Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

OK - So that I am clear...

IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.

The next step is then programming the FIB on the line card (if applicable).

Would make sense for IRS to not provide interface to the FIB on the second step.
But you are saying that it would also not provide interface to FIB of the first step. 

Is that correct?

/himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 6:05 PM
To: Shah, Himanshu
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I don't see IRS going below the RIB layer to FIB.

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> I will let Ed clarify on what he means by "controller" .
>
>
>
> But here is my view of "application", "controller", "use-case" etc 
> etc,
>
>
>
> When an XaaS processes a request it takes into consideration of 
> availability of the CPU, memory, application data, cost of power, etc.
> to instantiate a VM on some host machine.
>
> One additional resource taken into consideration is the availability 
> and/or requirement of the network connectivity between the resources
>
> such as VM, application data, requester, etc.
>
>
>
> The provider of XaaS thingy is the application server.
>
> (Centralized) Network "Controller(s)"  knows current state of network 
> infrastructure and (to be decided how much it) controls member network 
> nodes using IRS.
>
> The "use case" here is to be able to dynamically create L2/L2.5/L3 
> connectivity with specific TE characteristics between the (perhaps 
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> As we heard at IETF, IRS has tentacles in network nodes from BGP 
> policies, all the way down to FIBs/LFIBs/ACL.
>
>
>
> So we need use cases for which applications would require 
> accessibility to -
>
> BGP Policies
>
> RIB
>
> LSDB ( I saw an email which talks about reducing IGP to link 
> distribution protocol and running SPF in centralized network
> controller)
>
> LIB
>
> FIB
>
> ACL (this is perhaps obvious)
>
> Etc etc
>
>
>
> I broad brushed and simplified a lot here to express my view - not 
> sure if this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 1:30 PM
> To: Edward Crabbe; Alia Atlas
> Cc: David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> Thanks.  Can you also give us what you mean by "controller".
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone 
> +a few
> rounds with folks on this one in other forums, I'll point out that 
> what most people mean by application (myself included) is some set of 
> control software (a scheduler, a path optimizer etc)  that provides 
> instructions to the controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding 
> state without an intermediate broker/aggregator acting on their behalf 
> sounds like a recipe for disaster for operational networks, or, as is 
> more likely, a quick hike to the protocol grave yard (followed by a 
> long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not 
> expect that real user-land applications would talk directly to routing 
> devices via IRS.  I can see that going through an intermediary.  The 
> IRS abstractions are unlikely to be as high-level as user-land 
> applications would want and the security and policy issues would get 
> exciting.
>
> Clarifying what applications are more in-scope initially is part of 
> where use-cases will help.  Can you write up ones to 
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application 
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  
>> The draft talks very much as if the application we are addressing is 
>> an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by 
>> customers/users at the first Open Network Summit, there appears to be 
>> a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to 
>> ensure delivery of an HD video to an end user - the application will 
>> not be interested in the underlying topology of the network; it will 
>> need to know that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for 
>> ALL applications ?), or should we be more prescriptive about which 
>> application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define 
>> within that some motivating use-cases that we agree are good first 
>> targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the 
>> mailing list is a good first start.  Russ White is starting the 
>> general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes 
>> <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific 
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas 
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models 
>>> for sub-interfaces along with an associated protocol (whether that 
>>> is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of 
>>>> mails, so pardon the repeat if somebody has already raised the 
>>>> following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing 
>>>> to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to 
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent 
>>>> predictive action/response/events even when different 
>>>> implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, 
>>>> limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process 
>>>>>> gives good semantics and interactions.  Obviously, 
>>>>>> implementations may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the 
>>>>> operator to whatever precedence they want, I agree.  Its not clear 
>>>>> to me if various RIB implementations treat all proffered routes 
>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed 
>>>>> protocol-specific optimizations, without conflict from the other 
>>>>> routing processes, if they so desire.  OTOH if it can all be done 
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define 
>>>> the different precedences; my assumption is that it would be per 
>>>> route with a well-defined small set of meta-data.  This is part of 
>>>> where having good use-cases will help us understand what behavior 
>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 22:56:45 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: "UTTARO, JAMES" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

What is the benefit of allowing access to the FIB vs. the associated complexity?
If something wants to inject state directly into the forwarding plane,
isn't that what ForCES or OpenFlow is for?

Why get into low-level assembly when we've got a C-equiv?  (Still not
a higher level language that apps might speak with associated
abstractions, but closer).

Alia

On Wed, Aug 15, 2012 at 10:01 PM, Shah, Himanshu <[email-masked]> wrote:
> Yes I agree. I meant precedence value (pardon the use of wrong terminology).
> Each entity that injects route to routing table has an associated precedence value..
>
> Anyway, I am more curious to know why not allow access to FIB..
>
> /himanshu
>
> -----Original Message-----
> From: UTTARO, JAMES [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 7:50 PM
> To: Shah, Himanshu; Alia Atlas
> Cc: [email-masked]
> Subject: RE: [irs-discuss] IRS comments
>
> Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..
>
> Jim Uttaro
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 6:57 PM
> To: Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> OK - So that I am clear...
>
> IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.
>
> The next step is then programming the FIB on the line card (if applicable).
>
> Would make sense for IRS to not provide interface to the FIB on the second step.
> But you are saying that it would also not provide interface to FIB of the first step.
>
> Is that correct?
>
> /himanshu
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 6:05 PM
> To: Shah, Himanshu
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I don't see IRS going below the RIB layer to FIB.
>
> Alia
>
> On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
>> I will let Ed clarify on what he means by "controller" .
>>
>>
>>
>> But here is my view of "application", "controller", "use-case" etc
>> etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc.
>> to instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network "Controller(s)"  knows current state of network
>> infrastructure and (to be decided how much it) controls member network
>> nodes using IRS.
>>
>> The "use case" here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface) ->
>> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP
>> policies, all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require
>> accessibility to -
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view - not
>> sure if this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Thanks.  Can you also give us what you mean by "controller".
>>
>>
>>
>> Olen
>>
>>
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 1:24 PM
>> To: Alia Atlas
>> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> s/wg/pre-BOF proto-wg :P/g
>>
>> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having gone
>> +a few
>> rounds with folks on this one in other forums, I'll point out that
>> what most people mean by application (myself included) is some set of
>> control software (a scheduler, a path optimizer etc)  that provides
>> instructions to the controller, which are in turn translated to the appropriate PDUs.
>>
>>
>>
>> Having 'end user' applications request/make changes to forwarding
>> state without an intermediate broker/aggregator acting on their behalf
>> sounds like a recipe for disaster for operational networks, or, as is
>> more likely, a quick hike to the protocol grave yard (followed by a
>> long grave-side party
>> :P) for the wg.
>>
>>
>>
>> my 2c.
>>
>>
>>
>> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to routing
>> devices via IRS.  I can see that going through an intermediary.  The
>> IRS abstractions are unlikely to be as high-level as user-land
>> applications would want and the security and policy issues would get
>> exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
>> wrote:
>>> As another newbie to this, I have some questions about "application
>>> vendors."
>>>
>>> Who is the target audience here ?   That will determine what functionality
>>> and abstraction of the network we need to expose to that "application."
>>>
>>> This presently appears to be a little confused - at least in my mind.
>>> The draft talks very much as if the application we are addressing is
>>> an OSS/BSS system, essentially provisioning from the domain owner.
>>>
>>> However, linking this to the wider goals of SDN as voiced by
>>> customers/users at the first Open Network Summit, there appears to be
>>> a desire for cross-domain and user-land application integration.
>>>
>>> At this level - as an example giving a content cache the ability to
>>> ensure delivery of an HD video to an end user - the application will
>>> not be interested in the underlying topology of the network; it will
>>> need to know that application X can be delivered with parameters Y between reading from
>>> the content store to delivery to the user's browser.   How the stream
>>> traverses the infrastructure is immaterial.
>>>
>>> Are we intending that IRS satisfies BOTH these requirements (i.e. for
>>> ALL applications ?), or should we be more prescriptive about which
>>> application space we are addressing ?
>>>
>>> Thanks
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]]
>>> On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 7:23 AM
>>> To: Olen Stokes
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> I have not specifically heard from application vendors about this.
>>> My current plan is that we focus on a Use-Cases draft and define
>>> within that some motivating use-cases that we agree are good first
>>> targets.  Those can drive which subset of functionality we focus on.
>>>
>>> More use-cases are, of course, quite welcome.  Posting them to the
>>> mailing list is a good first start.  Russ White is starting the
>>> general use-cases draft based on the three use-cases that he sent to the list.
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>>> <[email-masked]>
>>> wrote:
>>>> Are there applications vendors out there that already have specific
>>>> requirements for what this " subset of the data-models for sub-interfaces"
>>>> should be?
>>>>
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>>> To: Shah, Himanshu
>>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>>> Nadeau; Alia Atlas; Scott Whyte
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> Hi Himanshu,
>>>>
>>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>>> formed - I expect that we'll focus on a subset of the data-models
>>>> for sub-interfaces along with an associated protocol (whether that
>>>> is a new one or extending an existing one).
>>>>
>>>> Alia
>>>>
>>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>>> Newbie to this discussions list and have read only a last couple of
>>>>> mails, so pardon the repeat if somebody has already raised the
>>>>> following as a concern.
>>>>>
>>>>> I realize we are early in IRS architecture definition but one thing
>>>>> to keep in mind is the user experience.
>>>>> We need to make sure that exposed interface to
>>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>>> predictive action/response/events even when different
>>>>> implementations has varying capabilities.
>>>>>
>>>>> At the moment it seems like a wild wild west.
>>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>>> limited version..
>>>>>
>>>>> Thanks,
>>>>> himanshu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>>> To: Scott Whyte
>>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>>> [email-masked]
>>>>> Subject: Re: [irs-discuss] IRS comments
>>>>>
>>>>> ...snip...
>>>>>
>>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>>
>>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>>> gives good semantics and interactions.  Obviously,
>>>>>>> implementations may differ.
>>>>>>
>>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>>> to me if various RIB implementations treat all proffered routes
>>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>>> So there needs to be some way for the operator to leverage exposed
>>>>>> protocol-specific optimizations, without conflict from the other
>>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>>> via static routes, it seems much simpler. :)
>>>>>
>>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>>>>> the different precedences; my assumption is that it would be per
>>>>> route with a well-defined small set of meta-data.  This is part of
>>>>> where having good use-cases will help us understand what behavior
>>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>>
>>>>> Alia
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 22:54:56 -0400
From: Alia Atlas <[email-masked]>
To: "UTTARO, JAMES" <[email-masked]>
Cc: "Shah, Himanshu" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Definitely agree - an IRS client has specific authorization and scope
for what it can do - and that includes what prioritization it can
specify for its static routes and so on..

Alia

On Wed, Aug 15, 2012 at 7:50 PM, UTTARO, JAMES <[email-masked]> wrote:
> Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..
>
> Jim Uttaro
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
> Sent: Wednesday, August 15, 2012 6:57 PM
> To: Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> OK - So that I am clear...
>
> IRS would provide interface to RIB such that routes can be injected with priority
> and the local routing table manager on the node would then apply precedence rules, select the route,
> do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.
>
> The next step is then programming the FIB on the line card (if applicable).
>
> Would make sense for IRS to not provide interface to the FIB on the second step.
> But you are saying that it would also not provide interface to FIB of the first step.
>
> Is that correct?
>
> /himanshu
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 6:05 PM
> To: Shah, Himanshu
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I don't see IRS going below the RIB layer to FIB.
>
> Alia
>
> On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
>> I will let Ed clarify on what he means by "controller" .
>>
>>
>>
>> But here is my view of "application", "controller", "use-case" etc
>> etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc.
>> to instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network "Controller(s)"  knows current state of network
>> infrastructure and (to be decided how much it) controls member network
>> nodes using IRS.
>>
>> The "use case" here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface) ->
>> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP
>> policies, all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require
>> accessibility to -
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view - not
>> sure if this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Thanks.  Can you also give us what you mean by "controller".
>>
>>
>>
>> Olen
>>
>>
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 1:24 PM
>> To: Alia Atlas
>> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> s/wg/pre-BOF proto-wg :P/g
>>
>> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having gone
>> +a few
>> rounds with folks on this one in other forums, I'll point out that
>> what most people mean by application (myself included) is some set of
>> control software (a scheduler, a path optimizer etc)  that provides
>> instructions to the controller, which are in turn translated to the appropriate PDUs.
>>
>>
>>
>> Having 'end user' applications request/make changes to forwarding
>> state without an intermediate broker/aggregator acting on their behalf
>> sounds like a recipe for disaster for operational networks, or, as is
>> more likely, a quick hike to the protocol grave yard (followed by a
>> long grave-side party
>> :P) for the wg.
>>
>>
>>
>> my 2c.
>>
>>
>>
>> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to routing
>> devices via IRS.  I can see that going through an intermediary.  The
>> IRS abstractions are unlikely to be as high-level as user-land
>> applications would want and the security and policy issues would get
>> exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
>> wrote:
>>> As another newbie to this, I have some questions about "application
>>> vendors."
>>>
>>> Who is the target audience here ?   That will determine what functionality
>>> and abstraction of the network we need to expose to that "application."
>>>
>>> This presently appears to be a little confused - at least in my mind.
>>> The draft talks very much as if the application we are addressing is
>>> an OSS/BSS system, essentially provisioning from the domain owner.
>>>
>>> However, linking this to the wider goals of SDN as voiced by
>>> customers/users at the first Open Network Summit, there appears to be
>>> a desire for cross-domain and user-land application integration.
>>>
>>> At this level - as an example giving a content cache the ability to
>>> ensure delivery of an HD video to an end user - the application will
>>> not be interested in the underlying topology of the network; it will
>>> need to know that application X can be delivered with parameters Y between reading from
>>> the content store to delivery to the user's browser.   How the stream
>>> traverses the infrastructure is immaterial.
>>>
>>> Are we intending that IRS satisfies BOTH these requirements (i.e. for
>>> ALL applications ?), or should we be more prescriptive about which
>>> application space we are addressing ?
>>>
>>> Thanks
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]]
>>> On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 7:23 AM
>>> To: Olen Stokes
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> I have not specifically heard from application vendors about this.
>>> My current plan is that we focus on a Use-Cases draft and define
>>> within that some motivating use-cases that we agree are good first
>>> targets.  Those can drive which subset of functionality we focus on.
>>>
>>> More use-cases are, of course, quite welcome.  Posting them to the
>>> mailing list is a good first start.  Russ White is starting the
>>> general use-cases draft based on the three use-cases that he sent to the list.
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>>> <[email-masked]>
>>> wrote:
>>>> Are there applications vendors out there that already have specific
>>>> requirements for what this " subset of the data-models for sub-interfaces"
>>>> should be?
>>>>
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>>> To: Shah, Himanshu
>>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>>> Nadeau; Alia Atlas; Scott Whyte
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> Hi Himanshu,
>>>>
>>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>>> formed - I expect that we'll focus on a subset of the data-models
>>>> for sub-interfaces along with an associated protocol (whether that
>>>> is a new one or extending an existing one).
>>>>
>>>> Alia
>>>>
>>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>>> Newbie to this discussions list and have read only a last couple of
>>>>> mails, so pardon the repeat if somebody has already raised the
>>>>> following as a concern.
>>>>>
>>>>> I realize we are early in IRS architecture definition but one thing
>>>>> to keep in mind is the user experience.
>>>>> We need to make sure that exposed interface to
>>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>>> predictive action/response/events even when different
>>>>> implementations has varying capabilities.
>>>>>
>>>>> At the moment it seems like a wild wild west.
>>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>>> limited version..
>>>>>
>>>>> Thanks,
>>>>> himanshu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>>> To: Scott Whyte
>>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>>> [email-masked]
>>>>> Subject: Re: [irs-discuss] IRS comments
>>>>>
>>>>> ...snip...
>>>>>
>>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>>
>>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>>> gives good semantics and interactions.  Obviously,
>>>>>>> implementations may differ.
>>>>>>
>>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>>> to me if various RIB implementations treat all proffered routes
>>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>>> So there needs to be some way for the operator to leverage exposed
>>>>>> protocol-specific optimizations, without conflict from the other
>>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>>> via static routes, it seems much simpler. :)
>>>>>
>>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>>>>> the different precedences; my assumption is that it would be per
>>>>> route with a well-defined small set of meta-data.  This is part of
>>>>> where having good use-cases will help us understand what behavior
>>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>>
>>>>> Alia
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 22:53:31 -0400
From: Alia Atlas <[email-masked]>
To: Lin Han <[email-masked]>
Cc: Olen Stokes <[email-masked]>, Edward Crabbe <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Good questions.

On Wed, Aug 15, 2012 at 9:56 PM, Lin Han <[email-masked]> wrote:
> Will IRS provide a channel for data such as data packet punt and injection? As you said inject OAM into the created LSP.

Given that an IRS agent can inject a static route or a policy-based
route, it is easy to specify an appropriate next-hop/tunnel to direct
packets to an appropriate location.
I do think that the ability to inject packets would be useful - though
I have concerns about scale for that - and it is somewhat arguable as
to whether it fits under the "routing system".

> Also, what is the good means of learning more topology and dynamic events and related state easily? Do you have any rough idea? I thought PCE has learnt all from the running protocol since it is part of the topo.

IRS is the means :-)  We're working on defining that based on the requirements.

Alia

> Lin
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 3:12 PM
> To: [email-masked]
> Cc: Olen Stokes; Edward Crabbe; David Lake (dlake); [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> On Wed, Aug 15, 2012 at 3:50 PM, Robert Raszuk <[email-masked]> wrote:
>>
>>>   It could just as easily describe a PCE.
>>
>>
>> PCE could be a controller just talking to headends and asking them to signal
>> LSP X with RSVP-TE or it could talk to all head, tail and via nodes and
>> actually program the forwarding label entries.
>>
>> I am observing that IRS framework is more of the former case rather then the
>> latter in general.
>>
>> However if this is the former then I am a bit not clear what value it is to
>> deliver if we compare it with current statefull PCE efforts ;)
>
> Other than providing a good means of learning more topology and
> dynamic events and related state easily??  Feedback loops - and an
> easy mechanism to, for instance, test a created LSP via OAM before
> declaring the new one up?
>
> Alia
>
>> Best,
>> R.
>>
>>
>>
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 22:47:47 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Yes, that's my current opinion.  Given that IRS can provide the
desired priority for the route within its constraints, and given that
there can be multiple IRS clients trying to specify routes, there's a
need for a local routing table manager to apply precedence regardless.

Alia

On Wed, Aug 15, 2012 at 6:57 PM, Shah, Himanshu <[email-masked]> wrote:
> OK - So that I am clear...
>
> IRS would provide interface to RIB such that routes can be injected with priority
> and the local routing table manager on the node would then apply precedence rules, select the route,
> do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.
>
> The next step is then programming the FIB on the line card (if applicable).
>
> Would make sense for IRS to not provide interface to the FIB on the second step.
> But you are saying that it would also not provide interface to FIB of the first step.
>
> Is that correct?
>
> /himanshu
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 6:05 PM
> To: Shah, Himanshu
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I don't see IRS going below the RIB layer to FIB.
>
> Alia
>
> On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
>> I will let Ed clarify on what he means by "controller" .
>>
>>
>>
>> But here is my view of "application", "controller", "use-case" etc
>> etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc.
>> to instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network "Controller(s)"  knows current state of network
>> infrastructure and (to be decided how much it) controls member network
>> nodes using IRS.
>>
>> The "use case" here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface) ->
>> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP
>> policies, all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require
>> accessibility to -
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link
>> distribution protocol and running SPF in centralized network
>> controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view - not
>> sure if this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Thanks.  Can you also give us what you mean by "controller".
>>
>>
>>
>> Olen
>>
>>
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 1:24 PM
>> To: Alia Atlas
>> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> s/wg/pre-BOF proto-wg :P/g
>>
>> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having gone
>> +a few
>> rounds with folks on this one in other forums, I'll point out that
>> what most people mean by application (myself included) is some set of
>> control software (a scheduler, a path optimizer etc)  that provides
>> instructions to the controller, which are in turn translated to the appropriate PDUs.
>>
>>
>>
>> Having 'end user' applications request/make changes to forwarding
>> state without an intermediate broker/aggregator acting on their behalf
>> sounds like a recipe for disaster for operational networks, or, as is
>> more likely, a quick hike to the protocol grave yard (followed by a
>> long grave-side party
>> :P) for the wg.
>>
>>
>>
>> my 2c.
>>
>>
>>
>> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to routing
>> devices via IRS.  I can see that going through an intermediary.  The
>> IRS abstractions are unlikely to be as high-level as user-land
>> applications would want and the security and policy issues would get
>> exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
>> wrote:
>>> As another newbie to this, I have some questions about "application
>>> vendors."
>>>
>>> Who is the target audience here ?   That will determine what functionality
>>> and abstraction of the network we need to expose to that "application."
>>>
>>> This presently appears to be a little confused - at least in my mind.
>>> The draft talks very much as if the application we are addressing is
>>> an OSS/BSS system, essentially provisioning from the domain owner.
>>>
>>> However, linking this to the wider goals of SDN as voiced by
>>> customers/users at the first Open Network Summit, there appears to be
>>> a desire for cross-domain and user-land application integration.
>>>
>>> At this level - as an example giving a content cache the ability to
>>> ensure delivery of an HD video to an end user - the application will
>>> not be interested in the underlying topology of the network; it will
>>> need to know that application X can be delivered with parameters Y between reading from
>>> the content store to delivery to the user's browser.   How the stream
>>> traverses the infrastructure is immaterial.
>>>
>>> Are we intending that IRS satisfies BOTH these requirements (i.e. for
>>> ALL applications ?), or should we be more prescriptive about which
>>> application space we are addressing ?
>>>
>>> Thanks
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]]
>>> On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 7:23 AM
>>> To: Olen Stokes
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> I have not specifically heard from application vendors about this.
>>> My current plan is that we focus on a Use-Cases draft and define
>>> within that some motivating use-cases that we agree are good first
>>> targets.  Those can drive which subset of functionality we focus on.
>>>
>>> More use-cases are, of course, quite welcome.  Posting them to the
>>> mailing list is a good first start.  Russ White is starting the
>>> general use-cases draft based on the three use-cases that he sent to the list.
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>>> <[email-masked]>
>>> wrote:
>>>> Are there applications vendors out there that already have specific
>>>> requirements for what this " subset of the data-models for sub-interfaces"
>>>> should be?
>>>>
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>>> To: Shah, Himanshu
>>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>>> Nadeau; Alia Atlas; Scott Whyte
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> Hi Himanshu,
>>>>
>>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>>> formed - I expect that we'll focus on a subset of the data-models
>>>> for sub-interfaces along with an associated protocol (whether that
>>>> is a new one or extending an existing one).
>>>>
>>>> Alia
>>>>
>>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>>> Newbie to this discussions list and have read only a last couple of
>>>>> mails, so pardon the repeat if somebody has already raised the
>>>>> following as a concern.
>>>>>
>>>>> I realize we are early in IRS architecture definition but one thing
>>>>> to keep in mind is the user experience.
>>>>> We need to make sure that exposed interface to
>>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent
>>>>> predictive action/response/events even when different
>>>>> implementations has varying capabilities.
>>>>>
>>>>> At the moment it seems like a wild wild west.
>>>>> Perhaps IRS can be defined in phases starting with a simpler,
>>>>> limited version..
>>>>>
>>>>> Thanks,
>>>>> himanshu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>>> To: Scott Whyte
>>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>>> [email-masked]
>>>>> Subject: Re: [irs-discuss] IRS comments
>>>>>
>>>>> ...snip...
>>>>>
>>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>>
>>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>>> gives good semantics and interactions.  Obviously,
>>>>>>> implementations may differ.
>>>>>>
>>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>>> to me if various RIB implementations treat all proffered routes
>>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>>> So there needs to be some way for the operator to leverage exposed
>>>>>> protocol-specific optimizations, without conflict from the other
>>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>>> via static routes, it seems much simpler. :)
>>>>>
>>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>>>>> the different precedences; my assumption is that it would be per
>>>>> route with a well-defined small set of meta-data.  This is part of
>>>>> where having good use-cases will help us understand what behavior
>>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>>
>>>>> Alia
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>

From: "Shah, Himanshu" <[email-masked]>
To: "UTTARO, JAMES" <[email-masked]>, Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 22:01:53 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Yes I agree. I meant precedence value (pardon the use of wrong terminology). 
Each entity that injects route to routing table has an associated precedence value..

Anyway, I am more curious to know why not allow access to FIB..

/himanshu

-----Original Message-----
From: UTTARO, JAMES [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 7:50 PM
To: Shah, Himanshu; Alia Atlas
Cc: [email-masked]
Subject: RE: [irs-discuss] IRS comments

Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 6:57 PM
To: Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

OK - So that I am clear...

IRS would provide interface to RIB such that routes can be injected with priority and the local routing table manager on the node would then apply precedence rules, select the route, do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.

The next step is then programming the FIB on the line card (if applicable).

Would make sense for IRS to not provide interface to the FIB on the second step.
But you are saying that it would also not provide interface to FIB of the first step. 

Is that correct?

/himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 6:05 PM
To: Shah, Himanshu
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I don't see IRS going below the RIB layer to FIB.

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> I will let Ed clarify on what he means by "controller" .
>
>
>
> But here is my view of "application", "controller", "use-case" etc 
> etc,
>
>
>
> When an XaaS processes a request it takes into consideration of 
> availability of the CPU, memory, application data, cost of power, etc.
> to instantiate a VM on some host machine.
>
> One additional resource taken into consideration is the availability 
> and/or requirement of the network connectivity between the resources
>
> such as VM, application data, requester, etc.
>
>
>
> The provider of XaaS thingy is the application server.
>
> (Centralized) Network "Controller(s)"  knows current state of network 
> infrastructure and (to be decided how much it) controls member network 
> nodes using IRS.
>
> The "use case" here is to be able to dynamically create L2/L2.5/L3 
> connectivity with specific TE characteristics between the (perhaps 
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> As we heard at IETF, IRS has tentacles in network nodes from BGP 
> policies, all the way down to FIBs/LFIBs/ACL.
>
>
>
> So we need use cases for which applications would require 
> accessibility to -
>
> BGP Policies
>
> RIB
>
> LSDB ( I saw an email which talks about reducing IGP to link 
> distribution protocol and running SPF in centralized network
> controller)
>
> LIB
>
> FIB
>
> ACL (this is perhaps obvious)
>
> Etc etc
>
>
>
> I broad brushed and simplified a lot here to express my view - not 
> sure if this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 1:30 PM
> To: Edward Crabbe; Alia Atlas
> Cc: David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> Thanks.  Can you also give us what you mean by "controller".
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone 
> +a few
> rounds with folks on this one in other forums, I'll point out that 
> what most people mean by application (myself included) is some set of 
> control software (a scheduler, a path optimizer etc)  that provides 
> instructions to the controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding 
> state without an intermediate broker/aggregator acting on their behalf 
> sounds like a recipe for disaster for operational networks, or, as is 
> more likely, a quick hike to the protocol grave yard (followed by a 
> long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not 
> expect that real user-land applications would talk directly to routing 
> devices via IRS.  I can see that going through an intermediary.  The 
> IRS abstractions are unlikely to be as high-level as user-land 
> applications would want and the security and policy issues would get 
> exciting.
>
> Clarifying what applications are more in-scope initially is part of 
> where use-cases will help.  Can you write up ones to 
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application 
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  
>> The draft talks very much as if the application we are addressing is 
>> an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by 
>> customers/users at the first Open Network Summit, there appears to be 
>> a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to 
>> ensure delivery of an HD video to an end user - the application will 
>> not be interested in the underlying topology of the network; it will 
>> need to know that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for 
>> ALL applications ?), or should we be more prescriptive about which 
>> application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define 
>> within that some motivating use-cases that we agree are good first 
>> targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the 
>> mailing list is a good first start.  Russ White is starting the 
>> general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes 
>> <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific 
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas 
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models 
>>> for sub-interfaces along with an associated protocol (whether that 
>>> is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of 
>>>> mails, so pardon the repeat if somebody has already raised the 
>>>> following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing 
>>>> to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to 
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent 
>>>> predictive action/response/events even when different 
>>>> implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, 
>>>> limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process 
>>>>>> gives good semantics and interactions.  Obviously, 
>>>>>> implementations may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the 
>>>>> operator to whatever precedence they want, I agree.  Its not clear 
>>>>> to me if various RIB implementations treat all proffered routes 
>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed 
>>>>> protocol-specific optimizations, without conflict from the other 
>>>>> routing processes, if they so desire.  OTOH if it can all be done 
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define 
>>>> the different precedences; my assumption is that it would be per 
>>>> route with a well-defined small set of meta-data.  This is part of 
>>>> where having good use-cases will help us understand what behavior 
>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: Lin Han <[email-masked]>
To: Alia Atlas <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 16 Aug 2012 01:56:30 +0000
Accept-Language: en-US, zh-CN
Cc: Olen Stokes <[email-masked]>, Edward Crabbe <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Will IRS provide a channel for data such as data packet punt and injection? As you said inject OAM into the created LSP.
Also, what is the good means of learning more topology and dynamic events and related state easily? Do you have any rough idea? I thought PCE has learnt all from the running protocol since it is part of the topo.

Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, August 15, 2012 3:12 PM
To: [email-masked]
Cc: Olen Stokes; Edward Crabbe; David Lake (dlake); [email-masked]
Subject: Re: [irs-discuss] IRS comments

On Wed, Aug 15, 2012 at 3:50 PM, Robert Raszuk <[email-masked]> wrote:
>
>>   It could just as easily describe a PCE.
>
>
> PCE could be a controller just talking to headends and asking them to signal
> LSP X with RSVP-TE or it could talk to all head, tail and via nodes and
> actually program the forwarding label entries.
>
> I am observing that IRS framework is more of the former case rather then the
> latter in general.
>
> However if this is the former then I am a bit not clear what value it is to
> deliver if we compare it with current statefull PCE efforts ;)

Other than providing a good means of learning more topology and
dynamic events and related state easily??  Feedback loops - and an
easy mechanism to, for instance, test a created LSP via OAM before
declaring the new one up?

Alia

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

From: "UTTARO, JAMES" <[email-masked]>
To: "'Shah, Himanshu'" <[email-masked]>, Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 23:50:08 +0000
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Inject routes yes, but I would not assume that implies that all state from IRS is prioritized.. I think an important point to remember is that how IRS interfaces with routing state learned via network protocols needs to be part of this effort..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shah, Himanshu
Sent: Wednesday, August 15, 2012 6:57 PM
To: Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

OK - So that I am clear...

IRS would provide interface to RIB such that routes can be injected with priority
and the local routing table manager on the node would then apply precedence rules, select the route,
do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.

The next step is then programming the FIB on the line card (if applicable).

Would make sense for IRS to not provide interface to the FIB on the second step.
But you are saying that it would also not provide interface to FIB of the first step. 

Is that correct?

/himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 6:05 PM
To: Shah, Himanshu
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I don't see IRS going below the RIB layer to FIB.

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> I will let Ed clarify on what he means by "controller" .
>
>
>
> But here is my view of "application", "controller", "use-case" etc 
> etc,
>
>
>
> When an XaaS processes a request it takes into consideration of 
> availability of the CPU, memory, application data, cost of power, etc. 
> to instantiate a VM on some host machine.
>
> One additional resource taken into consideration is the availability 
> and/or requirement of the network connectivity between the resources
>
> such as VM, application data, requester, etc.
>
>
>
> The provider of XaaS thingy is the application server.
>
> (Centralized) Network "Controller(s)"  knows current state of network 
> infrastructure and (to be decided how much it) controls member network 
> nodes using IRS.
>
> The "use case" here is to be able to dynamically create L2/L2.5/L3 
> connectivity with specific TE characteristics between the (perhaps 
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> As we heard at IETF, IRS has tentacles in network nodes from BGP 
> policies, all the way down to FIBs/LFIBs/ACL.
>
>
>
> So we need use cases for which applications would require 
> accessibility to -
>
> BGP Policies
>
> RIB
>
> LSDB ( I saw an email which talks about reducing IGP to link 
> distribution protocol and running SPF in centralized network 
> controller)
>
> LIB
>
> FIB
>
> ACL (this is perhaps obvious)
>
> Etc etc
>
>
>
> I broad brushed and simplified a lot here to express my view - not 
> sure if this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 1:30 PM
> To: Edward Crabbe; Alia Atlas
> Cc: David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> Thanks.  Can you also give us what you mean by "controller".
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone 
> +a few
> rounds with folks on this one in other forums, I'll point out that 
> what most people mean by application (myself included) is some set of 
> control software (a scheduler, a path optimizer etc)  that provides 
> instructions to the controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding 
> state without an intermediate broker/aggregator acting on their behalf 
> sounds like a recipe for disaster for operational networks, or, as is 
> more likely, a quick hike to the protocol grave yard (followed by a 
> long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not 
> expect that real user-land applications would talk directly to routing 
> devices via IRS.  I can see that going through an intermediary.  The 
> IRS abstractions are unlikely to be as high-level as user-land 
> applications would want and the security and policy issues would get 
> exciting.
>
> Clarifying what applications are more in-scope initially is part of 
> where use-cases will help.  Can you write up ones to 
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application 
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  
>> The draft talks very much as if the application we are addressing is 
>> an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by 
>> customers/users at the first Open Network Summit, there appears to be 
>> a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to 
>> ensure delivery of an HD video to an end user - the application will 
>> not be interested in the underlying topology of the network; it will  
>> need to know that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for 
>> ALL applications ?), or should we be more prescriptive about which 
>> application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define 
>> within that some motivating use-cases that we agree are good first 
>> targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the 
>> mailing list is a good first start.  Russ White is starting the 
>> general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes 
>> <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific 
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas 
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models 
>>> for sub-interfaces along with an associated protocol (whether that 
>>> is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of 
>>>> mails, so pardon the repeat if somebody has already raised the 
>>>> following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing 
>>>> to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to 
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent 
>>>> predictive action/response/events even when different 
>>>> implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, 
>>>> limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process 
>>>>>> gives good semantics and interactions.  Obviously, 
>>>>>> implementations may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the 
>>>>> operator to whatever precedence they want, I agree.  Its not clear 
>>>>> to me if various RIB implementations treat all proffered routes 
>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed 
>>>>> protocol-specific optimizations, without conflict from the other 
>>>>> routing processes, if they so desire.  OTOH if it can all be done 
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define 
>>>> the different precedences; my assumption is that it would be per 
>>>> route with a well-defined small set of meta-data.  This is part of 
>>>> where having good use-cases will help us understand what behavior 
>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Shah, Himanshu" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 18:57:13 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

OK - So that I am clear...

IRS would provide interface to RIB such that routes can be injected with priority
and the local routing table manager on the node would then apply precedence rules, select the route,
do ARP resolve (if ETH) and inject the prefix with next-hop info into the FIB.

The next step is then programming the FIB on the line card (if applicable).

Would make sense for IRS to not provide interface to the FIB on the second step.
But you are saying that it would also not provide interface to FIB of the first step. 

Is that correct?

/himanshu

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 6:05 PM
To: Shah, Himanshu
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I don't see IRS going below the RIB layer to FIB.

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> I will let Ed clarify on what he means by "controller" .
>
>
>
> But here is my view of "application", "controller", "use-case" etc 
> etc,
>
>
>
> When an XaaS processes a request it takes into consideration of 
> availability of the CPU, memory, application data, cost of power, etc. 
> to instantiate a VM on some host machine.
>
> One additional resource taken into consideration is the availability 
> and/or requirement of the network connectivity between the resources
>
> such as VM, application data, requester, etc.
>
>
>
> The provider of XaaS thingy is the application server.
>
> (Centralized) Network "Controller(s)"  knows current state of network 
> infrastructure and (to be decided how much it) controls member network 
> nodes using IRS.
>
> The "use case" here is to be able to dynamically create L2/L2.5/L3 
> connectivity with specific TE characteristics between the (perhaps 
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> As we heard at IETF, IRS has tentacles in network nodes from BGP 
> policies, all the way down to FIBs/LFIBs/ACL.
>
>
>
> So we need use cases for which applications would require 
> accessibility to -
>
> BGP Policies
>
> RIB
>
> LSDB ( I saw an email which talks about reducing IGP to link 
> distribution protocol and running SPF in centralized network 
> controller)
>
> LIB
>
> FIB
>
> ACL (this is perhaps obvious)
>
> Etc etc
>
>
>
> I broad brushed and simplified a lot here to express my view - not 
> sure if this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 1:30 PM
> To: Edward Crabbe; Alia Atlas
> Cc: David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> Thanks.  Can you also give us what you mean by "controller".
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone 
> +a few
> rounds with folks on this one in other forums, I'll point out that 
> what most people mean by application (myself included) is some set of 
> control software (a scheduler, a path optimizer etc)  that provides 
> instructions to the controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding 
> state without an intermediate broker/aggregator acting on their behalf 
> sounds like a recipe for disaster for operational networks, or, as is 
> more likely, a quick hike to the protocol grave yard (followed by a 
> long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not 
> expect that real user-land applications would talk directly to routing 
> devices via IRS.  I can see that going through an intermediary.  The 
> IRS abstractions are unlikely to be as high-level as user-land 
> applications would want and the security and policy issues would get 
> exciting.
>
> Clarifying what applications are more in-scope initially is part of 
> where use-cases will help.  Can you write up ones to 
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application 
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  
>> The draft talks very much as if the application we are addressing is 
>> an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by 
>> customers/users at the first Open Network Summit, there appears to be 
>> a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to 
>> ensure delivery of an HD video to an end user - the application will 
>> not be interested in the underlying topology of the network; it will  
>> need to know that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for 
>> ALL applications ?), or should we be more prescriptive about which 
>> application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked] 
>> [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define 
>> within that some motivating use-cases that we agree are good first 
>> targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the 
>> mailing list is a good first start.  Russ White is starting the 
>> general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes 
>> <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific 
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas 
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models 
>>> for sub-interfaces along with an associated protocol (whether that 
>>> is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of 
>>>> mails, so pardon the repeat if somebody has already raised the 
>>>> following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing 
>>>> to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to 
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent 
>>>> predictive action/response/events even when different 
>>>> implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, 
>>>> limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process 
>>>>>> gives good semantics and interactions.  Obviously, 
>>>>>> implementations may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the 
>>>>> operator to whatever precedence they want, I agree.  Its not clear 
>>>>> to me if various RIB implementations treat all proffered routes 
>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed 
>>>>> protocol-specific optimizations, without conflict from the other 
>>>>> routing processes, if they so desire.  OTOH if it can all be done 
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define 
>>>> the different precedences; my assumption is that it would be per 
>>>> route with a well-defined small set of meta-data.  This is part of 
>>>> where having good use-cases will help us understand what behavior 
>>>> is necessary.  The static routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>

Date: Wed, 15 Aug 2012 18:11:56 -0400
From: Alia Atlas <[email-masked]>
To: [email-masked]
Cc: Olen Stokes <[email-masked]>, Edward Crabbe <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

On Wed, Aug 15, 2012 at 3:50 PM, Robert Raszuk <[email-masked]> wrote:
>
>>   It could just as easily describe a PCE.
>
>
> PCE could be a controller just talking to headends and asking them to signal
> LSP X with RSVP-TE or it could talk to all head, tail and via nodes and
> actually program the forwarding label entries.
>
> I am observing that IRS framework is more of the former case rather then the
> latter in general.
>
> However if this is the former then I am a bit not clear what value it is to
> deliver if we compare it with current statefull PCE efforts ;)

Other than providing a good means of learning more topology and
dynamic events and related state easily??  Feedback loops - and an
easy mechanism to, for instance, test a created LSP via OAM before
declaring the new one up?

Alia

> Best,
> R.
>
>
>
>

Date: Wed, 15 Aug 2012 18:10:12 -0400
From: Alia Atlas <[email-masked]>
To: Olen Stokes <[email-masked]>
Cc: Edward Crabbe <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I don't think it implies a reference to an OpenFlow Controller.  An
IRS client might live in a controller application that serves a
similar functional role.  This is part of what use-cases may help
with.

Alia

On Wed, Aug 15, 2012 at 2:38 PM, Olen Stokes
<[email-masked]> wrote:
> I understand that.  Sorry, I should have been more specific.  I am trying to
> understand if usage of the word “controller” on this list implies a
> reference to any existing description such as “Open Flow Controller”.
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 2:20 PM
> To: Olen Stokes
> Cc: Alia Atlas; David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> The software (interacting with the 'applications' and) generating the actual
> PDUs understood by the NEs.
>
>
>
> On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <[email-masked]>
> wrote:
>
> Thanks.  Can you also give us what you mean by “controller”.
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone a few
> rounds with folks on this one in other forums, I'll point out that what most
> people mean by application (myself included) is some set of control software
> (a scheduler, a path optimizer etc)  that provides instructions to the
> controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds like
> a recipe for disaster for operational networks, or, as is more likely, a
> quick hike to the protocol grave yard (followed by a long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  The
>> draft talks very much as if the application we are addressing is an OSS/BSS
>> system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by
>> customers/users at the first Open Network Summit, there appears to be a
>> desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to ensure
>> delivery of an HD video to an end user - the application will not be
>> interested in the underlying topology of the network; it will  need to know
>> that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL
>> applications ?), or should we be more prescriptive about which application
>> space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define within
>> that some motivating use-cases that we agree are good first targets.  Those
>> can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the mailing
>> list is a good first start.  Russ White is starting the general use-cases
>> draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
>>> Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models for
>>> sub-interfaces along with an associated protocol (whether that is a new one
>>> or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of
>>>> mails, so pardon the repeat if somebody has already raised the following as
>>>> a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing to
>>>> keep in mind is the user experience.
>>>> We need to make sure that exposed interface to
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
>>>> action/response/events even when different implementations has varying
>>>> capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, limited
>>>> version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>>> may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>> to me if various RIB implementations treat all proffered routes the
>>>>> same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed
>>>>> protocol-specific optimizations, without conflict from the other
>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the
>>>> different precedences; my assumption is that it would be per route with a
>>>> well-defined small set of meta-data.  This is part of where having good
>>>> use-cases will help us understand what behavior is necessary.  The static
>>>> routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
>
>

Date: Wed, 15 Aug 2012 18:09:06 -0400
From: Alia Atlas <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

On Wed, Aug 15, 2012 at 2:26 PM, Edward Crabbe <[email-masked]> wrote:
> It's not clear to me that IRS has 'tentacles' (;)) in the LFIB...

Perhaps the correct term is the LIB rather than the LFIB....   This is
the control plane's mapping of incoming MPLS label to next-hops with
associated label operations.

(I think of them as puppet strings rather than tentacles - but if you
prefer a more aquatic description...)

> Is this the case?  And if so, I guess I'll repeat the question I asked after
> Alia's presentation in the RTG meeting:  will there be a mechanism to
> negotiate and specify encapsulation types as well as form FECs etc?

I think of a next-hop as including the outgoing interface and
encapsulation type, with associated details.  I've got that in the IRS
framework draft in the RIB sub-interface description.   Could you take
a look and tell me what, at a high level, you see as missing?

> On Wed, Aug 15, 2012 at 11:21 AM, Shah, Himanshu <[email-masked]> wrote:
>>
>> I will let Ed clarify on what he means by “controller” .
>>
>>
>>
>> But here is my view of “application”, “controller”, “use-case” etc etc,
>>
>>
>>
>> When an XaaS processes a request it takes into consideration of
>> availability of the CPU, memory, application data, cost of power, etc. to
>> instantiate a VM on some host machine.
>>
>> One additional resource taken into consideration is the availability
>> and/or requirement of the network connectivity between the resources
>>
>> such as VM, application data, requester, etc.
>>
>>
>>
>> The provider of XaaS thingy is the application server.
>>
>> (Centralized) Network “Controller(s)”  knows current state of network
>> infrastructure and (to be decided how much it) controls member network nodes
>> using IRS.
>>
>> The “use case” here is to be able to dynamically create L2/L2.5/L3
>> connectivity with specific TE characteristics between the (perhaps
>> geographically dispersed) resource points.
>>
>>
>>
>> In hierarchical fashion:   Application server <- (application interface)
>> -> Network Controller <- (IRS) -> Network Node
>>
>>
>>
>> As we heard at IETF, IRS has tentacles in network nodes from BGP policies,
>> all the way down to FIBs/LFIBs/ACL.
>>
>>
>>
>> So we need use cases for which applications would require accessibility to
>> –
>>
>> BGP Policies
>>
>> RIB
>>
>> LSDB ( I saw an email which talks about reducing IGP to link distribution
>> protocol and running SPF in centralized network controller)
>>
>> LIB
>>
>> FIB
>>
>> ACL (this is perhaps obvious)
>>
>> Etc etc
>>
>>
>>
>> I broad brushed and simplified a lot here to express my view – not sure if
>> this jives with others.
>>
>>
>>
>> /Himanshu
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Olen Stokes
>> Sent: Wednesday, August 15, 2012 1:30 PM
>> To: Edward Crabbe; Alia Atlas
>> Cc: David Lake (dlake); [email-masked]
>>
>>
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> Thanks.  Can you also give us what you mean by “controller”.
>>
>>
>>
>> Olen
>>
>>
>>
>> From: Edward Crabbe [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 1:24 PM
>> To: Alia Atlas
>> Cc: David Lake (dlake); Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>>
>> s/wg/pre-BOF proto-wg :P/g
>>
>> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having gone a
>> few rounds with folks on this one in other forums, I'll point out that what
>> most people mean by application (myself included) is some set of control
>> software (a scheduler, a path optimizer etc)  that provides instructions to
>> the controller, which are in turn translated to the appropriate PDUs.
>>
>>
>>
>> Having 'end user' applications request/make changes to forwarding state
>> without an intermediate broker/aggregator acting on their behalf sounds like
>> a recipe for disaster for operational networks, or, as is more likely, a
>> quick hike to the protocol grave yard (followed by a long grave-side party
>> :P) for the wg.
>>
>>
>>
>> my 2c.
>>
>>
>>
>> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to routing
>> devices via IRS.  I can see that going through an intermediary.  The
>> IRS abstractions are unlikely to be as high-level as user-land
>> applications would want and the security and policy issues would get
>> exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
>> wrote:
>> > As another newbie to this, I have some questions about "application
>> > vendors."
>> >
>> > Who is the target audience here ?   That will determine what
>> > functionality and abstraction of the network we need to expose to that
>> > "application."
>> >
>> > This presently appears to be a little confused - at least in my mind.
>> > The draft talks very much as if the application we are addressing is an
>> > OSS/BSS system, essentially provisioning from the domain owner.
>> >
>> > However, linking this to the wider goals of SDN as voiced by
>> > customers/users at the first Open Network Summit, there appears to be a
>> > desire for cross-domain and user-land application integration.
>> >
>> > At this level - as an example giving a content cache the ability to
>> > ensure delivery of an HD video to an end user - the application will not be
>> > interested in the underlying topology of the network; it will  need to know
>> > that application X can be delivered with parameters Y between reading from
>> > the content store to delivery to the user's browser.   How the stream
>> > traverses the infrastructure is immaterial.
>> >
>> > Are we intending that IRS satisfies BOTH these requirements (i.e. for
>> > ALL applications ?), or should we be more prescriptive about which
>> > application space we are addressing ?
>> >
>> > Thanks
>> >
>> > David
>> >
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]]
>> > On Behalf Of Alia Atlas
>> > Sent: Wednesday, August 15, 2012 7:23 AM
>> > To: Olen Stokes
>> > Cc: [email-masked]
>> > Subject: Re: [irs-discuss] IRS comments
>> >
>> > I have not specifically heard from application vendors about this.
>> > My current plan is that we focus on a Use-Cases draft and define within
>> > that some motivating use-cases that we agree are good first targets.  Those
>> > can drive which subset of functionality we focus on.
>> >
>> > More use-cases are, of course, quite welcome.  Posting them to the
>> > mailing list is a good first start.  Russ White is starting the general
>> > use-cases draft based on the three use-cases that he sent to the list.
>> >
>> > Alia
>> >
>> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>> > <[email-masked]> wrote:
>> >> Are there applications vendors out there that already have specific
>> >> requirements for what this " subset of the data-models for sub-interfaces"
>> >> should be?
>> >>
>> >> Olen
>> >>
>> >> -----Original Message-----
>> >> From: [email-masked]
>> >> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> >> Sent: Wednesday, August 15, 2012 9:08 AM
>> >> To: Shah, Himanshu
>> >> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
>> >> Alia Atlas; Scott Whyte
>> >> Subject: Re: [irs-discuss] IRS comments
>> >>
>> >> Hi Himanshu,
>> >>
>> >> Welcome.   I agree that IRS isn't going to spring into being fully
>> >> formed - I expect that we'll focus on a subset of the data-models for
>> >> sub-interfaces along with an associated protocol (whether that is a new one
>> >> or extending an existing one).
>> >>
>> >> Alia
>> >>
>> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]>
>> >> wrote:
>> >>> Newbie to this discussions list and have read only a last couple of
>> >>> mails, so pardon the repeat if somebody has already raised the following as
>> >>> a concern.
>> >>>
>> >>> I realize we are early in IRS architecture definition but one thing to
>> >>> keep in mind is the user experience.
>> >>> We need to make sure that exposed interface to
>> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
>> >>> action/response/events even when different implementations has varying
>> >>> capabilities.
>> >>>
>> >>> At the moment it seems like a wild wild west.
>> >>> Perhaps IRS can be defined in phases starting with a simpler, limited
>> >>> version..
>> >>>
>> >>> Thanks,
>> >>> himanshu
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: [email-masked]
>> >>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> >>> Sent: Monday, August 13, 2012 8:41 AM
>> >>> To: Scott Whyte
>> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>> >>> [email-masked]
>> >>> Subject: Re: [irs-discuss] IRS comments
>> >>>
>> >>> ...snip...
>> >>>
>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]>
>> >>> wrote:
>> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]>
>> >>>> wrote:
>> >>>
>> >>>>> I do think it is important to have the RIB as an arbitration
>> >>>>> mechanism
>> >>>>> on the device.   Russ's suggestion that for the RIB sub-interface,
>> >>>>> the
>> >>>>> IRS agent might communicate logically to an IRS routing process
>> >>>>> gives good semantics and interactions.  Obviously, implementations
>> >>>>> may differ.
>> >>>>
>> >>>> As long as the arbitration mechanism is reconfigurable by the
>> >>>> operator to whatever precedence they want, I agree.  Its not clear
>> >>>> to me if various RIB implementations treat all proffered routes the
>> >>>> same, nor if they store the same meta-data with all protocol sources.
>> >>>> So there needs to be some way for the operator to leverage exposed
>> >>>> protocol-specific optimizations, without conflict from the other
>> >>>> routing processes, if they so desire.  OTOH if it can all be done
>> >>>> via static routes, it seems much simpler. :)
>> >>>
>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>> >>> the different precedences; my assumption is that it would be per route with
>> >>> a well-defined small set of meta-data.  This is part of where having good
>> >>> use-cases will help us understand what behavior is necessary.  The static
>> >>> routes do seem like a simpler case to start with.
>> >>>
>> >>> Alia
>> >>> _______________________________________________
>> >>> irs-discuss mailing list
>> >>> [email-masked]
>> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> >> _______________________________________________
>> >> irs-discuss mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>> > _______________________________________________
>> > irs-discuss mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>>
>
>

Date: Wed, 15 Aug 2012 18:04:40 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I don't see IRS going below the RIB layer to FIB.

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> I will let Ed clarify on what he means by “controller” .
>
>
>
> But here is my view of “application”, “controller”, “use-case” etc etc,
>
>
>
> When an XaaS processes a request it takes into consideration of availability
> of the CPU, memory, application data, cost of power, etc. to instantiate a
> VM on some host machine.
>
> One additional resource taken into consideration is the availability and/or
> requirement of the network connectivity between the resources
>
> such as VM, application data, requester, etc.
>
>
>
> The provider of XaaS thingy is the application server.
>
> (Centralized) Network “Controller(s)”  knows current state of network
> infrastructure and (to be decided how much it) controls member network nodes
> using IRS.
>
> The “use case” here is to be able to dynamically create L2/L2.5/L3
> connectivity with specific TE characteristics between the (perhaps
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> As we heard at IETF, IRS has tentacles in network nodes from BGP policies,
> all the way down to FIBs/LFIBs/ACL.
>
>
>
> So we need use cases for which applications would require accessibility to –
>
> BGP Policies
>
> RIB
>
> LSDB ( I saw an email which talks about reducing IGP to link distribution
> protocol and running SPF in centralized network controller)
>
> LIB
>
> FIB
>
> ACL (this is perhaps obvious)
>
> Etc etc
>
>
>
> I broad brushed and simplified a lot here to express my view – not sure if
> this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 1:30 PM
> To: Edward Crabbe; Alia Atlas
> Cc: David Lake (dlake); [email-masked]
>
>
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> Thanks.  Can you also give us what you mean by “controller”.
>
>
>
> Olen
>
>
>
> From: Edward Crabbe [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 1:24 PM
> To: Alia Atlas
> Cc: David Lake (dlake); Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
>
>
> s/wg/pre-BOF proto-wg :P/g
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone a few
> rounds with folks on this one in other forums, I'll point out that what most
> people mean by application (myself included) is some set of control software
> (a scheduler, a path optimizer etc)  that provides instructions to the
> controller, which are in turn translated to the appropriate PDUs.
>
>
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds like
> a recipe for disaster for operational networks, or, as is more likely, a
> quick hike to the protocol grave yard (followed by a long grave-side party
> :P) for the wg.
>
>
>
> my 2c.
>
>
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
>> As another newbie to this, I have some questions about "application
>> vendors."
>>
>> Who is the target audience here ?   That will determine what functionality
>> and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  The
>> draft talks very much as if the application we are addressing is an OSS/BSS
>> system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by
>> customers/users at the first Open Network Summit, there appears to be a
>> desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to ensure
>> delivery of an HD video to an end user - the application will not be
>> interested in the underlying topology of the network; it will  need to know
>> that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL
>> applications ?), or should we be more prescriptive about which application
>> space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define within
>> that some motivating use-cases that we agree are good first targets.  Those
>> can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the mailing
>> list is a good first start.  Russ White is starting the general use-cases
>> draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]>
>> wrote:
>>> Are there applications vendors out there that already have specific
>>> requirements for what this " subset of the data-models for sub-interfaces"
>>> should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
>>> Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models for
>>> sub-interfaces along with an associated protocol (whether that is a new one
>>> or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of
>>>> mails, so pardon the repeat if somebody has already raised the following as
>>>> a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing to
>>>> keep in mind is the user experience.
>>>> We need to make sure that exposed interface to
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
>>>> action/response/events even when different implementations has varying
>>>> capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, limited
>>>> version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>>> may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>> to me if various RIB implementations treat all proffered routes the
>>>>> same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed
>>>>> protocol-specific optimizations, without conflict from the other
>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the
>>>> different precedences; my assumption is that it would be per route with a
>>>> well-defined small set of meta-data.  This is part of where having good
>>>> use-cases will help us understand what behavior is necessary.  The static
>>>> routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>

Date: Wed, 15 Aug 2012 21:50:25 +0200
From: Robert Raszuk <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: Alia Atlas <[email-masked]>, Olen Stokes <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments
Reply-To: [email-masked]

>   It could just as easily describe a PCE.

PCE could be a controller just talking to headends and asking them to 
signal LSP X with RSVP-TE or it could talk to all head, tail and via 
nodes and actually program the forwarding label entries.

I am observing that IRS framework is more of the former case rather then 
the latter in general.

However if this is the former then I am a bit not clear what value it is 
to deliver if we compare it with current statefull PCE efforts ;)

Best,
R.

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 11:56:49 -0700
To: Olen Stokes <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--14dae9340929a8e16e04c7527f05
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

Olen,

Nope, I'm using it in a very general sense.  It could just as easily
describe a PCE.

On Wed, Aug 15, 2012 at 11:38 AM, Olen Stokes
<[email-masked]>wrote:

> I understand that.  Sorry, I should have been more specific.  I am trying
> to understand if usage of the word “controller” on this list implies a
> reference to any existing description such as “Open Flow Controller”.****
>
> ** **
>
> Olen****
>
> ** **
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Wednesday, August 15, 2012 2:20 PM
> *To:* Olen Stokes
> *Cc:* Alia Atlas; David Lake (dlake); [email-masked]
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
> ** **
>
> The software (interacting with the 'applications' and) generating the
> actual PDUs understood by the NEs. ****
>
> ** **
>
> On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <[email-masked]>
> wrote:****
>
> Thanks.  Can you also give us what you mean by “controller”.  ****
>
>  ****
>
> Olen****
>
>  ****
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Wednesday, August 15, 2012 1:24 PM
> *To:* Alia Atlas
> *Cc:* David Lake (dlake); Olen Stokes; [email-masked]****
>
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
>  ****
>
> s/wg/pre-BOF proto-wg :P/g  ****
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:***
> *
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone a
> few rounds with folks on this one in other forums, I'll point out that what
> most people mean by application (myself included) is some set of control
> software (a scheduler, a path optimizer etc)  that provides instructions to
> the controller, which are in turn translated to the appropriate PDUs.****
>
>  ****
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds
> like a recipe for disaster for operational networks, or, as is more likely,
> a quick hike to the protocol grave yard (followed by a long grave-side
> party :P) for the wg.  ****
>
>  ****
>
> my 2c. ****
>
>  ****
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:****
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia****
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
> > As another newbie to this, I have some questions about "application
> vendors."
> >
> > Who is the target audience here ?   That will determine what
> functionality and abstraction of the network we need to expose to that
> "application."
> >
> > This presently appears to be a little confused - at least in my mind.
>  The draft talks very much as if the application we are addressing is an
> OSS/BSS system, essentially provisioning from the domain owner.
> >
> > However, linking this to the wider goals of SDN as voiced by
> customers/users at the first Open Network Summit, there appears to be a
> desire for cross-domain and user-land application integration.
> >
> > At this level - as an example giving a content cache the ability to
> ensure delivery of an HD video to an end user - the application will not be
> interested in the underlying topology of the network; it will  need to know
> that application X can be delivered with parameters Y between reading from
> the content store to delivery to the user's browser.   How the stream
> traverses the infrastructure is immaterial.
> >
> > Are we intending that IRS satisfies BOTH these requirements (i.e. for
> ALL applications ?), or should we be more prescriptive about which
> application space we are addressing ?
> >
> > Thanks
> >
> > David
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Alia Atlas
> > Sent: Wednesday, August 15, 2012 7:23 AM
> > To: Olen Stokes
> > Cc: [email-masked]
> > Subject: Re: [irs-discuss] IRS comments
> >
> > I have not specifically heard from application vendors about this.
> > My current plan is that we focus on a Use-Cases draft and define within
> that some motivating use-cases that we agree are good first targets.  Those
> can drive which subset of functionality we focus on.
> >
> > More use-cases are, of course, quite welcome.  Posting them to the
> mailing list is a good first start.  Russ White is starting the general
> use-cases draft based on the three use-cases that he sent to the list.
> >
> > Alia
> >
> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <
> [email-masked]> wrote:
> >> Are there applications vendors out there that already have specific
> requirements for what this " subset of the data-models for sub-interfaces"
>  should be?
> >>
> >> Olen
> >>
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >> Sent: Wednesday, August 15, 2012 9:08 AM
> >> To: Shah, Himanshu
> >> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
> >> Alia Atlas; Scott Whyte
> >> Subject: Re: [irs-discuss] IRS comments
> >>
> >> Hi Himanshu,
> >>
> >> Welcome.   I agree that IRS isn't going to spring into being fully
> >> formed - I expect that we'll focus on a subset of the data-models for
> sub-interfaces along with an associated protocol (whether that is a new one
> or extending an existing one).
> >>
> >> Alia
> >>
> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]>
> wrote:
> >>> Newbie to this discussions list and have read only a last couple of
> mails, so pardon the repeat if somebody has already raised the following as
> a concern.
> >>>
> >>> I realize we are early in IRS architecture definition but one thing to
> keep in mind is the user experience.
> >>> We need to make sure that exposed interface to
> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
> action/response/events even when different implementations has varying
> capabilities.
> >>>
> >>> At the moment it seems like a wild wild west.
> >>> Perhaps IRS can be defined in phases starting with a simpler, limited
> version..
> >>>
> >>> Thanks,
> >>> himanshu
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >>> Sent: Monday, August 13, 2012 8:41 AM
> >>> To: Scott Whyte
> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
> >>> [email-masked]
> >>> Subject: Re: [irs-discuss] IRS comments
> >>>
> >>> ...snip...
> >>>
> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]>
> wrote:
> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]>
> wrote:
> >>>
> >>>>> I do think it is important to have the RIB as an arbitration
> mechanism
> >>>>> on the device.   Russ's suggestion that for the RIB sub-interface,
> the
> >>>>> IRS agent might communicate logically to an IRS routing process
> >>>>> gives good semantics and interactions.  Obviously, implementations
> >>>>> may differ.
> >>>>
> >>>> As long as the arbitration mechanism is reconfigurable by the
> >>>> operator to whatever precedence they want, I agree.  Its not clear
> >>>> to me if various RIB implementations treat all proffered routes the
> >>>> same, nor if they store the same meta-data with all protocol sources.
> >>>> So there needs to be some way for the operator to leverage exposed
> >>>> protocol-specific optimizations, without conflict from the other
> >>>> routing processes, if they so desire.  OTOH if it can all be done
> >>>> via static routes, it seems much simpler. :)
> >>>
> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define
> the different precedences; my assumption is that it would be per route with
> a well-defined small set of meta-data.  This is part of where having good
> use-cases will help us understand what behavior is necessary.  The static
>  routes do seem like a simpler case to start with.
> >>>
> >>> Alia
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> > _______________________________________________
> > irs-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
>  ****
>
>  ****
>
> ** **
>

--14dae9340929a8e16e04c7527f05
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div>Olen,</div><div><br></div>Nope, I&#39;m using it in a very general sense.  It could just as easily describe a PCE.   <br><br><div class="gmail_quote">On Wed, Aug 15, 2012 at 11:38 AM, Olen Stokes <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"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">I understand that.  Sorry, I should have been more specific.  I am trying to understand if usage of the word “controller” on this list implies a reference to any existing description such as “Open Flow Controller”.<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Olen<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><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;"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b>Sent:</b> Wednesday, August 15, 2012 2:20 PM<br><b>To:</b> Olen Stokes<br><b>Cc:</b> Alia Atlas; David Lake (dlake); <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></p><div><div class="h5">

<br><b>Subject:</b> Re: [irs-discuss] IRS comments<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">The software (interacting with the &#39;applications&#39; and) generating the actual PDUs understood by the NEs. <u></u><u></u></p>

<div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></p>

<div><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Thanks.  Can you also give us what you mean by “controller”.  </span><u></u><u></u></p><p class="MsoNormal">

<span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Olen</span><u></u><u></u></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"> </span><u></u><u></u></p><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;"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b>Sent:</b> Wednesday, August 15, 2012 1:24 PM<br><b>To:</b> Alia Atlas<br><b>Cc:</b> David Lake (dlake); Olen Stokes; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span><u></u><u></u></p>

<div><div><p class="MsoNormal"><br><b>Subject:</b> Re: [irs-discuss] IRS comments<u></u><u></u></p></div></div><div><div><p class="MsoNormal"> <u></u><u></u></p><p class="MsoNormal" style="margin-bottom:12.0pt">s/wg/pre-BOF proto-wg :P/g  <u></u><u></u></p>

<div><p class="MsoNormal">On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></p><p class="MsoNormal">+1 Alia.  There&#39;s been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I&#39;ll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<u></u><u></u></p>

<div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">Having &#39;end user&#39; applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.  <u></u><u></u></p>

</div><div><p class="MsoNormal"> <u></u><u></u></p></div><div><p class="MsoNormal">my 2c. <u></u><u></u></p></div><div><div><div><p class="MsoNormal"> <u></u><u></u></p><div><p class="MsoNormal">On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></p>

<p class="MsoNormal">Hi David,<br><br>We do need to clarify what is meant by an application.  I would not<br>expect that real user-land applications would talk directly to routing<br>devices via IRS.  I can see that going through an intermediary.  The<br>

IRS abstractions are unlikely to be as high-level as user-land<br>applications would want and the security and policy issues would get<br>exciting.<br><br>Clarifying what applications are more in-scope initially is part of<br>

where use-cases will help.  Can you write up ones to<br>categorize/describe your thoughts?<br><span style="color:#888888"><br>Alia</span><u></u><u></u></p><div><div><p class="MsoNormal"><br>On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>

&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>&gt;<br>&gt; Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>

&gt;<br>&gt; This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>

&gt;<br>&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>&gt;<br>
&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user&#39;s browser.   How the stream traverses the infrastructure is immaterial.<br>

&gt;<br>&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>&gt;<br>&gt; Thanks<br>&gt;<br>

&gt; David<br>&gt;<br>&gt; -----Original Message-----<br>&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>&gt; To: Olen Stokes<br>&gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;<br>
&gt; I have not specifically heard from application vendors about this.<br>
&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.<br>&gt;<br>&gt; More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>

&gt;<br>&gt; Alia<br>&gt;<br>&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot;  should be?<br>

&gt;&gt;<br>&gt;&gt; Olen<br>&gt;&gt;<br>&gt;&gt; -----Original Message-----<br>&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>&gt;&gt; To: Shah, Himanshu<br>&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>

&gt;&gt; Alia Atlas; Scott Whyte<br>&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;<br>&gt;&gt; Hi Himanshu,<br>&gt;&gt;<br>&gt;&gt; Welcome.   I agree that IRS isn&#39;t going to spring into being fully<br>
&gt;&gt; formed - I expect that we&#39;ll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>
&gt;&gt;<br>&gt;&gt; Alia<br>&gt;&gt;<br>&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>&gt;&gt;&gt; We need to make sure that exposed interface to<br>&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt; himanshu<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; -----Original Message-----<br>&gt;&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>&gt;&gt;&gt; To: Scott Whyte<br>&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ...snip...<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>

&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>

&gt;&gt;&gt;&gt;&gt; on the device.   Russ&#39;s suggestion that for the RIB sub-interface, the<br>&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions.  Obviously, implementations<br>

&gt;&gt;&gt;&gt;&gt; may differ.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree.  Its not clear<br>

&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>

&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>&gt;&gt;&gt;&gt; routing processes, if they so desire.  OTOH if it can all be done<br>&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; Alia<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; irs-discuss mailing list<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt;&gt; _______________________________________________<br>&gt;&gt; irs-discuss mailing list<br>

&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>

&gt; _______________________________________________<br>&gt; irs-discuss mailing list<br>&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>

_______________________________________________<br>irs-discuss mailing list<br><a href="mailto:[email-masked]" target="_blank">[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><u></u><u></u></p>

</div></div></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div><p class="MsoNormal"> <u></u><u></u></p></div></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></div>

</blockquote></div><br>

--14dae9340929a8e16e04c7527f05--

From: Olen Stokes <[email-masked]>
To: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 11:38:01 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

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

I understand that.  Sorry, I should have been more specific.  I am trying to understand if usage of the word "controller" on this list implies a reference to any existing description such as "Open Flow Controller".

Olen

From: Edward Crabbe [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 2:20 PM
To: Olen Stokes
Cc: Alia Atlas; David Lake (dlake); [email-masked]
Subject: Re: [irs-discuss] IRS comments

The software (interacting with the 'applications' and) generating the actual PDUs understood by the NEs.

On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <[email-masked]<mailto:[email-masked]>> wrote:
Thanks.  Can you also give us what you mean by "controller".

Olen

From: Edward Crabbe [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 15, 2012 1:24 PM
To: Alia Atlas
Cc: David Lake (dlake); Olen Stokes; [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] IRS comments

s/wg/pre-BOF proto-wg :P/g
On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]<mailto:[email-masked]>> wrote:
+1 Alia.  There's been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I'll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.

Having 'end user' applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.

my 2c.

On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

We do need to clarify what is meant by an application.  I would not
expect that real user-land applications would talk directly to routing
devices via IRS.  I can see that going through an intermediary.  The
IRS abstractions are unlikely to be as high-level as user-land
applications would want and the security and policy issues would get
exciting.

Clarifying what applications are more in-scope initially is part of
where use-cases will help.  Can you write up ones to
categorize/describe your thoughts?

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]<mailto:[email-masked]>> wrote:
> As another newbie to this, I have some questions about "application vendors."
>
> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>
> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>
> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]<mailto:[email-masked]>> wrote:
>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>
>> Olen
>>
>> -----Original Message-----
>> From: [email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: Gert Grammel; [email-masked]<mailto:[email-masked]>; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>>
>> Welcome.   I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]<mailto:[email-masked]>> wrote:
>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>> We need to make sure that exposed interface to
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.
>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>
>>> Thanks,
>>> himanshu
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]<mailto:[email-masked]>
>>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>> [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]<mailto:[email-masked]>> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>> IRS agent might communicate logically to an IRS routing process
>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>> may differ.
>>>>
>>>> As long as the arbitration mechanism is reconfigurable by the
>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>> to me if various RIB implementations treat all proffered routes the
>>>> same, nor if they store the same meta-data with all protocol sources.
>>>> So there needs to be some way for the operator to leverage exposed
>>>> protocol-specific optimizations, without conflict from the other
>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>> via static routes, it seems much simpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>
>>> Alia
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE8E4USEXCHANGEc_
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: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
	{mso-style-priority:99;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
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.EmailStyle20
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@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'>I understand that.&nbsp; Sorry, I should have been more specific.&nbsp; I am trying to understand if usage of the word &#8220;controller&#8221; on this list implies a reference to any existing description such as &#8220;Open Flow Controller&#8221;.<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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Olen<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><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"'> Edward Crabbe [mailto:[email-masked]] <br><b>Sent:</b> Wednesday, August 15, 2012 2:20 PM<br><b>To:</b> Olen Stokes<br><b>Cc:</b> Alia Atlas; David Lake (dlake); [email-masked]<br><b>Subject:</b> Re: [irs-discuss] IRS comments<o:p></o:p></span></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal>The software (interacting with the 'applications' and) generating the actual PDUs understood by the NEs.&nbsp;<o:p></o:p></p><div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal>On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks.&nbsp; Can you also give us what you mean by &#8220;controller&#8221;.&nbsp; </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Olen</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>&nbsp;</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><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"'> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br><b>Sent:</b> Wednesday, August 15, 2012 1:24 PM<br><b>To:</b> Alia Atlas<br><b>Cc:</b> David Lake (dlake); Olen Stokes; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span><o:p></o:p></p><div><div><p class=MsoNormal><br><b>Subject:</b> Re: [irs-discuss] IRS comments<o:p></o:p></p></div></div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'>s/wg/pre-BOF proto-wg :P/g &nbsp;<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>+1 Alia. &nbsp;There's been a lot of confusion over this term. &nbsp;Having gone a few rounds with folks on this one in other forums, I'll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc) &nbsp;that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Having 'end user' applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg. &nbsp;<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p></o:p></p></div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>my 2c.&nbsp;<o:p></o:p></p></div><div><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p></o:p></p><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Hi David,<br><br>We do need to clarify what is meant by an application. &nbsp;I would not<br>expect that real user-land applications would talk directly to routing<br>devices via IRS. &nbsp;I can see that going through an intermediary. &nbsp;The<br>IRS abstractions are unlikely to be as high-level as user-land<br>applications would want and the security and policy issues would get<br>exciting.<br><br>Clarifying what applications are more in-scope initially is part of<br>where use-cases will help. &nbsp;Can you write up ones to<br>categorize/describe your thoughts?<br><span style='color:#888888'><br>Alia</span><o:p></o:p></p><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><br>On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>&gt;<br>&gt; Who is the target audience here ? &nbsp; That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>&gt;<br>&gt; This presently appears to be a little confused - at least in my mind. &nbsp;The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>&gt;<br>&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>&gt;<br>&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will &nbsp;need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser. &nbsp; How the stream traverses the infrastructure is immaterial.<br>&gt;<br>&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>&gt;<br>&gt; Thanks<br>&gt;<br>&gt; David<br>&gt;<br>&gt; -----Original Message-----<br>&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>&gt; To: Olen Stokes<br>&gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;<br>&gt; I have not specifically heard from application vendors about this.<br>&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets. &nbsp;Those can drive which subset of functionality we focus on.<br>&gt;<br>&gt; More use-cases are, of course, quite welcome. &nbsp;Posting them to the mailing list is a good first start. &nbsp;Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>&gt;<br>&gt; Alia<br>&gt;<br>&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot; &nbsp;should be?<br>&gt;&gt;<br>&gt;&gt; Olen<br>&gt;&gt;<br>&gt;&gt; -----Original Message-----<br>&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>&gt;&gt; To: Shah, Himanshu<br>&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>&gt;&gt; Alia Atlas; Scott Whyte<br>&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;<br>&gt;&gt; Hi Himanshu,<br>&gt;&gt;<br>&gt;&gt; Welcome. &nbsp; I agree that IRS isn't going to spring into being fully<br>&gt;&gt; formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>&gt;&gt;<br>&gt;&gt; Alia<br>&gt;&gt;<br>&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>&gt;&gt;&gt; We need to make sure that exposed interface to<br>&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc &nbsp;provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt; himanshu<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; -----Original Message-----<br>&gt;&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>&gt;&gt;&gt; To: Scott Whyte<br>&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ...snip...<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>&gt;&gt;&gt;&gt;&gt; on the device. &nbsp; Russ's suggestion that for the RIB sub-interface, the<br>&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions. &nbsp;Obviously, implementations<br>&gt;&gt;&gt;&gt;&gt; may differ.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree. &nbsp;Its not clear<br>&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>&gt;&gt;&gt;&gt; routing processes, if they so desire. &nbsp;OTOH if it can all be done<br>&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data. &nbsp;This is part of where having good use-cases will help us understand what behavior is necessary. &nbsp;The static &nbsp;routes do seem like a simpler case to start with.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Alia<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; irs-discuss mailing list<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt;&gt; _______________________________________________<br>&gt;&gt; irs-discuss mailing list<br>&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt; _______________________________________________<br>&gt; irs-discuss mailing list<br>&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>_______________________________________________<br>irs-discuss mailing list<br><a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></p></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p></o:p></p></div></div></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>&nbsp;<o:p></o:p></p></div></div></div></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></div></body></html>
--_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE8E4USEXCHANGEc_--

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 11:26:13 -0700
To: "Shah, Himanshu" <[email-masked]>
Cc: Olen Stokes <[email-masked]>, "[email-masked]" <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--bcaec529972f4285f804c75212ee
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

It's not clear to me that IRS has 'tentacles' (;)) in the LFIB...

Is this the case?  And if so, I guess I'll repeat the question I asked
after Alia's presentation in the RTG meeting:  will there be a mechanism to
negotiate and specify encapsulation types as well as form FECs etc?

On Wed, Aug 15, 2012 at 11:21 AM, Shah, Himanshu <[email-masked]> wrote:

> *I will let Ed clarify on what he means by “controller” .*
>
> * *
>
> *But here is my view of “application”, “controller”, “use-case” etc etc, *
>
> * *
>
> *When an XaaS processes a request it takes into consideration of
> availability of the CPU, memory, application data, cost of power, etc. to
> instantiate a VM on some host machine.*
>
> *One additional resource taken into consideration is the availability
> and/or requirement of the network connectivity between the resources*
>
> *such as VM, application data, requester, etc.*
>
> * *
>
> *The provider of XaaS thingy is the application server.*
>
> *(Centralized) Network “Controller(s)”  knows current state of network
> infrastructure and (to be decided how much it) controls member network
> nodes using IRS.*
>
> *The “use case” here is to be able to dynamically create L2/L2.5/L3
> connectivity with specific TE characteristics between the (perhaps
> geographically dispersed) resource points.*
>
> * *
>
> *In hierarchical fashion:   Application server <- (application interface)
> -> Network Controller <- (IRS) -> Network Node*
>
> * *
>
> *As we heard at IETF, IRS has tentacles in network nodes from BGP
> policies, all the way down to FIBs/LFIBs/ACL.*
>
> * *
>
> *So we need use cases for which applications would require accessibility
> to –*
>
> *BGP Policies*
>
> *RIB*
>
> *LSDB ( I saw an email which talks about reducing IGP to link
> distribution protocol and running SPF in centralized network controller)*
>
> *LIB*
>
> *FIB*
>
> *ACL (this is perhaps obvious)*
>
> *Etc etc*
>
> * *
>
> *I broad brushed and simplified a lot here to express my view – not sure
> if this jives with others.*
>
> * *
>
> */Himanshu*
>
> * *
>
> * *
>
> * *
>
> * *
>
> * *
>
> * *
>
> * *
>
> * *
>
> *From:* [email-masked] [mailto:[email-masked]]
> *On Behalf Of *Olen Stokes
> *Sent:* Wednesday, August 15, 2012 1:30 PM
> *To:* Edward Crabbe; Alia Atlas
> *Cc:* David Lake (dlake); [email-masked]
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
> ** **
>
> Thanks.  Can you also give us what you mean by “controller”.  ****
>
> ** **
>
> Olen****
>
> ** **
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Wednesday, August 15, 2012 1:24 PM
> *To:* Alia Atlas
> *Cc:* David Lake (dlake); Olen Stokes; [email-masked]
> *Subject:* Re: [irs-discuss] IRS comments****
>
> ** **
>
> s/wg/pre-BOF proto-wg :P/g  ****
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:***
> *
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone a
> few rounds with folks on this one in other forums, I'll point out that what
> most people mean by application (myself included) is some set of control
> software (a scheduler, a path optimizer etc)  that provides instructions to
> the controller, which are in turn translated to the appropriate PDUs.****
>
> ** **
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds
> like a recipe for disaster for operational networks, or, as is more likely,
> a quick hike to the protocol grave yard (followed by a long grave-side
> party :P) for the wg.  ****
>
> ** **
>
> my 2c. ****
>
> ** **
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:****
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia****
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
> > As another newbie to this, I have some questions about "application
> vendors."
> >
> > Who is the target audience here ?   That will determine what
> functionality and abstraction of the network we need to expose to that
> "application."
> >
> > This presently appears to be a little confused - at least in my mind.
>  The draft talks very much as if the application we are addressing is an
> OSS/BSS system, essentially provisioning from the domain owner.
> >
> > However, linking this to the wider goals of SDN as voiced by
> customers/users at the first Open Network Summit, there appears to be a
> desire for cross-domain and user-land application integration.
> >
> > At this level - as an example giving a content cache the ability to
> ensure delivery of an HD video to an end user - the application will not be
> interested in the underlying topology of the network; it will  need to know
> that application X can be delivered with parameters Y between reading from
> the content store to delivery to the user's browser.   How the stream
> traverses the infrastructure is immaterial.
> >
> > Are we intending that IRS satisfies BOTH these requirements (i.e. for
> ALL applications ?), or should we be more prescriptive about which
> application space we are addressing ?
> >
> > Thanks
> >
> > David
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Alia Atlas
> > Sent: Wednesday, August 15, 2012 7:23 AM
> > To: Olen Stokes
> > Cc: [email-masked]
> > Subject: Re: [irs-discuss] IRS comments
> >
> > I have not specifically heard from application vendors about this.
> > My current plan is that we focus on a Use-Cases draft and define within
> that some motivating use-cases that we agree are good first targets.  Those
> can drive which subset of functionality we focus on.
> >
> > More use-cases are, of course, quite welcome.  Posting them to the
> mailing list is a good first start.  Russ White is starting the general
> use-cases draft based on the three use-cases that he sent to the list.
> >
> > Alia
> >
> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <
> [email-masked]> wrote:
> >> Are there applications vendors out there that already have specific
> requirements for what this " subset of the data-models for sub-interfaces"
>  should be?
> >>
> >> Olen
> >>
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >> Sent: Wednesday, August 15, 2012 9:08 AM
> >> To: Shah, Himanshu
> >> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
> >> Alia Atlas; Scott Whyte
> >> Subject: Re: [irs-discuss] IRS comments
> >>
> >> Hi Himanshu,
> >>
> >> Welcome.   I agree that IRS isn't going to spring into being fully
> >> formed - I expect that we'll focus on a subset of the data-models for
> sub-interfaces along with an associated protocol (whether that is a new one
> or extending an existing one).
> >>
> >> Alia
> >>
> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]>
> wrote:
> >>> Newbie to this discussions list and have read only a last couple of
> mails, so pardon the repeat if somebody has already raised the following as
> a concern.
> >>>
> >>> I realize we are early in IRS architecture definition but one thing to
> keep in mind is the user experience.
> >>> We need to make sure that exposed interface to
> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
> action/response/events even when different implementations has varying
> capabilities.
> >>>
> >>> At the moment it seems like a wild wild west.
> >>> Perhaps IRS can be defined in phases starting with a simpler, limited
> version..
> >>>
> >>> Thanks,
> >>> himanshu
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >>> Sent: Monday, August 13, 2012 8:41 AM
> >>> To: Scott Whyte
> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
> >>> [email-masked]
> >>> Subject: Re: [irs-discuss] IRS comments
> >>>
> >>> ...snip...
> >>>
> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]>
> wrote:
> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]>
> wrote:
> >>>
> >>>>> I do think it is important to have the RIB as an arbitration
> mechanism
> >>>>> on the device.   Russ's suggestion that for the RIB sub-interface,
> the
> >>>>> IRS agent might communicate logically to an IRS routing process
> >>>>> gives good semantics and interactions.  Obviously, implementations
> >>>>> may differ.
> >>>>
> >>>> As long as the arbitration mechanism is reconfigurable by the
> >>>> operator to whatever precedence they want, I agree.  Its not clear
> >>>> to me if various RIB implementations treat all proffered routes the
> >>>> same, nor if they store the same meta-data with all protocol sources.
> >>>> So there needs to be some way for the operator to leverage exposed
> >>>> protocol-specific optimizations, without conflict from the other
> >>>> routing processes, if they so desire.  OTOH if it can all be done
> >>>> via static routes, it seems much simpler. :)
> >>>
> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define
> the different precedences; my assumption is that it would be per route with
> a well-defined small set of meta-data.  This is part of where having good
> use-cases will help us understand what behavior is necessary.  The static
>  routes do seem like a simpler case to start with.
> >>>
> >>> Alia
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> > _______________________________________________
> > irs-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
> ** **
>
> ** **
>

--bcaec529972f4285f804c75212ee
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

It&#39;s not clear to me that IRS has &#39;tentacles&#39; (;)) in the LFIB...  <div><br></div><div>Is this the case?  And if so, I guess I&#39;ll repeat the question I asked after Alia&#39;s presentation in the RTG meeting:  will there be a mechanism to negotiate and specify encapsulation types as well as form FECs etc? <br>

<br><div class="gmail_quote">On Wed, Aug 15, 2012 at 11:21 AM, Shah, Himanshu <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">

<div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">I will let Ed clarify on what he means by “controller” .<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">But here is my view of “application”, “controller”, “use-case” etc etc, <u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">When an XaaS processes a request it takes into consideration of availability of the CPU, memory, application data, cost of power, etc. to instantiate a VM on some host machine.<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">One additional resource taken into consideration is the availability and/or requirement of the network connectivity between the resources<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">such as VM, application data, requester, etc.<u></u><u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">The provider of XaaS thingy is the application server.<u></u><u></u></span></i></p><p class="MsoNormal">

<i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">(Centralized) Network “Controller(s)”  knows current state of network infrastructure and (to be decided how much it) controls member network nodes using IRS.<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">The “use case” here is to be able to dynamically create L2/L2.5/L3 connectivity with specific TE characteristics between the (perhaps geographically dispersed) resource points.<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">In hierarchical fashion:   Application server &lt;- (application interface) -&gt; Network Controller &lt;- (IRS) -&gt; Network Node<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">As we heard at IETF, IRS has tentacles in network nodes from BGP policies, all the way down to FIBs/LFIBs/ACL.<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">So we need use cases for which applications would require accessibility to –<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">BGP Policies<u></u><u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">RIB<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">LSDB ( I saw an email which talks about reducing IGP to link distribution protocol and running SPF in centralized network controller)<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">LIB<u></u><u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">FIB<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">ACL (this is perhaps obvious)<u></u><u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">Etc etc<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">I broad brushed and simplified a lot here to express my view – not sure if this jives with others.<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff">/Himanshu<u></u><u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p>

<p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></p><p class="MsoNormal"><i><span style="font-size:10.5pt;font-family:&quot;Candara&quot;,&quot;sans-serif&quot;;color:#0066ff"><u></u> <u></u></span></i></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;"> <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <b>On Behalf Of </b>Olen Stokes<br>

<b>Sent:</b> Wednesday, August 15, 2012 1:30 PM<br><b>To:</b> Edward Crabbe; Alia Atlas<br><b>Cc:</b> David Lake (dlake); <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></p><div><div class="h5">

<br><b>Subject:</b> Re: [irs-discuss] IRS comments<u></u><u></u></div></div><p></p></div></div><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Thanks.  Can you also give us what you mean by “controller”.  <u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Olen<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><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;"> Edward Crabbe <a href="mailto:[mailto:[email-masked]]" target="_blank">[mailto:[email-masked]]</a> <br>

<b>Sent:</b> Wednesday, August 15, 2012 1:24 PM<br><b>To:</b> Alia Atlas<br><b>Cc:</b> David Lake (dlake); Olen Stokes; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br><b>Subject:</b> Re: [irs-discuss] IRS comments<u></u><u></u></span></p>

<p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-bottom:12.0pt">s/wg/pre-BOF proto-wg :P/g  <u></u><u></u></p><div><p class="MsoNormal">On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></p>

<p class="MsoNormal">+1 Alia.  There&#39;s been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I&#39;ll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<u></u><u></u></p>

<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Having &#39;end user&#39; applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.  <u></u><u></u></p>

</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">my 2c. <u></u><u></u></p></div><div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></p>

<p class="MsoNormal">Hi David,<br><br>We do need to clarify what is meant by an application.  I would not<br>expect that real user-land applications would talk directly to routing<br>devices via IRS.  I can see that going through an intermediary.  The<br>

IRS abstractions are unlikely to be as high-level as user-land<br>applications would want and the security and policy issues would get<br>exciting.<br><br>Clarifying what applications are more in-scope initially is part of<br>

where use-cases will help.  Can you write up ones to<br>categorize/describe your thoughts?<br><span style="color:#888888"><br>Alia</span><u></u><u></u></p><div><div><p class="MsoNormal"><br>On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>

&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>&gt;<br>&gt; Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>

&gt;<br>&gt; This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>

&gt;<br>&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>&gt;<br>
&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user&#39;s browser.   How the stream traverses the infrastructure is immaterial.<br>

&gt;<br>&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>&gt;<br>&gt; Thanks<br>&gt;<br>

&gt; David<br>&gt;<br>&gt; -----Original Message-----<br>&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>&gt; To: Olen Stokes<br>&gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;<br>
&gt; I have not specifically heard from application vendors about this.<br>
&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.<br>&gt;<br>&gt; More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>

&gt;<br>&gt; Alia<br>&gt;<br>&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot;  should be?<br>

&gt;&gt;<br>&gt;&gt; Olen<br>&gt;&gt;<br>&gt;&gt; -----Original Message-----<br>&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>&gt;&gt; To: Shah, Himanshu<br>&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>

&gt;&gt; Alia Atlas; Scott Whyte<br>&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;<br>&gt;&gt; Hi Himanshu,<br>&gt;&gt;<br>&gt;&gt; Welcome.   I agree that IRS isn&#39;t going to spring into being fully<br>
&gt;&gt; formed - I expect that we&#39;ll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>
&gt;&gt;<br>&gt;&gt; Alia<br>&gt;&gt;<br>&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>&gt;&gt;&gt; We need to make sure that exposed interface to<br>&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt; himanshu<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; -----Original Message-----<br>&gt;&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>&gt;&gt;&gt; To: Scott Whyte<br>&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ...snip...<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>

&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>

&gt;&gt;&gt;&gt;&gt; on the device.   Russ&#39;s suggestion that for the RIB sub-interface, the<br>&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions.  Obviously, implementations<br>

&gt;&gt;&gt;&gt;&gt; may differ.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree.  Its not clear<br>

&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>

&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>&gt;&gt;&gt;&gt; routing processes, if they so desire.  OTOH if it can all be done<br>&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; Alia<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; irs-discuss mailing list<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt;&gt; _______________________________________________<br>&gt;&gt; irs-discuss mailing list<br>

&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>

&gt; _______________________________________________<br>&gt; irs-discuss mailing list<br>&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>

_______________________________________________<br>irs-discuss mailing list<br><a href="mailto:[email-masked]" target="_blank">[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><u></u><u></u></p>

</div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></blockquote></div><br></div>

--bcaec529972f4285f804c75212ee--

From: "Shah, Himanshu" <[email-masked]>
To: Olen Stokes <[email-masked]>, Edward Crabbe <[email-masked]>,  Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 14:21:28 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

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

I will let Ed clarify on what he means by "controller" .

But here is my view of "application", "controller", "use-case" etc etc,

When an XaaS processes a request it takes into consideration of availability of the CPU, memory, application data, cost of power, etc. to instantiate a VM on some host machine.
One additional resource taken into consideration is the availability and/or requirement of the network connectivity between the resources
such as VM, application data, requester, etc.

The provider of XaaS thingy is the application server.
(Centralized) Network "Controller(s)"  knows current state of network infrastructure and (to be decided how much it) controls member network nodes using IRS.
The "use case" here is to be able to dynamically create L2/L2.5/L3 connectivity with specific TE characteristics between the (perhaps geographically dispersed) resource points.

In hierarchical fashion:   Application server <- (application interface) -> Network Controller <- (IRS) -> Network Node

As we heard at IETF, IRS has tentacles in network nodes from BGP policies, all the way down to FIBs/LFIBs/ACL.

So we need use cases for which applications would require accessibility to -
BGP Policies
RIB
LSDB ( I saw an email which talks about reducing IGP to link distribution protocol and running SPF in centralized network controller)
LIB
FIB
ACL (this is perhaps obvious)
Etc etc

I broad brushed and simplified a lot here to express my view - not sure if this jives with others.

/Himanshu

From: [email-masked] [mailto:[email-masked]] On Behalf Of Olen Stokes
Sent: Wednesday, August 15, 2012 1:30 PM
To: Edward Crabbe; Alia Atlas
Cc: David Lake (dlake); [email-masked]
Subject: Re: [irs-discuss] IRS comments

Thanks.  Can you also give us what you mean by "controller".

Olen

From: Edward Crabbe [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, August 15, 2012 1:24 PM
To: Alia Atlas
Cc: David Lake (dlake); Olen Stokes; [email-masked]<mailto:[email-masked]>
Subject: Re: [irs-discuss] IRS comments

s/wg/pre-BOF proto-wg :P/g
On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]<mailto:[email-masked]>> wrote:
+1 Alia.  There's been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I'll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.

Having 'end user' applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.

my 2c.

On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

We do need to clarify what is meant by an application.  I would not
expect that real user-land applications would talk directly to routing
devices via IRS.  I can see that going through an intermediary.  The
IRS abstractions are unlikely to be as high-level as user-land
applications would want and the security and policy issues would get
exciting.

Clarifying what applications are more in-scope initially is part of
where use-cases will help.  Can you write up ones to
categorize/describe your thoughts?

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]<mailto:[email-masked]>> wrote:
> As another newbie to this, I have some questions about "application vendors."
>
> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>
> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>
> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]<mailto:[email-masked]>> wrote:
>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>
>> Olen
>>
>> -----Original Message-----
>> From: [email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: Gert Grammel; [email-masked]<mailto:[email-masked]>; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>>
>> Welcome.   I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]<mailto:[email-masked]>> wrote:
>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>> We need to make sure that exposed interface to
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.
>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>
>>> Thanks,
>>> himanshu
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]<mailto:[email-masked]>
>>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>> [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]<mailto:[email-masked]>> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>> IRS agent might communicate logically to an IRS routing process
>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>> may differ.
>>>>
>>>> As long as the arbitration mechanism is reconfigurable by the
>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>> to me if various RIB implementations treat all proffered routes the
>>>> same, nor if they store the same meta-data with all protocol sources.
>>>> So there needs to be some way for the operator to leverage exposed
>>>> protocol-specific optimizations, without conflict from the other
>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>> via static routes, it seems much simpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>
>>> Alia
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0MDWEXGMB02cie_
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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
	{font-family:Candara;
	panose-1:2 14 5 2 3 3 3 2 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* 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.EmailStyle17
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
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-reply;
	font-family:"Candara","sans-serif";
	color:#0066FF;
	font-weight:normal;
	font-style:italic;}
.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><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>I will let Ed clarify on what he means by &#8220;controller&#8221; .<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>But here is my view of &#8220;application&#8221;, &#8220;controller&#8221;, &#8220;use-case&#8221; etc etc, <o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>When an XaaS processes a request it takes into consideration of availability of the CPU, memory, application data, cost of power, etc. to instantiate a VM on some host machine.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>One additional resource taken into consideration is the availability and/or requirement of the network connectivity between the resources<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>such as VM, application data, requester, etc.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>The provider of XaaS thingy is the application server.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>(Centralized) Network &#8220;Controller(s)&#8221; &nbsp;knows current state of network infrastructure and (to be decided how much it) controls member network nodes using IRS.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>The &#8220;use case&#8221; here is to be able to dynamically create L2/L2.5/L3 connectivity with specific TE characteristics between the (perhaps geographically dispersed) resource points.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>In hierarchical fashion:&nbsp;&nbsp; Application server &lt;- (application interface) -&gt; Network Controller &lt;- (IRS) -&gt; Network Node<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>As we heard at IETF, IRS has tentacles in network nodes from BGP policies, all the way down to FIBs/LFIBs/ACL.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>So we need use cases for which applications would require accessibility to &#8211;<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>BGP Policies<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>RIB<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>LSDB ( I saw an email which talks about reducing IGP to link distribution protocol and running SPF in centralized network controller)<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>LIB<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>FIB<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>ACL (this is perhaps obvious)<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>Etc etc<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>I broad brushed and simplified a lot here to express my view &#8211; not sure if this jives with others.<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'>/Himanshu<o:p></o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></p><p class=MsoNormal><i><span style='font-size:10.5pt;font-family:"Candara","sans-serif";color:#0066FF'><o:p>&nbsp;</o:p></span></i></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>Olen Stokes<br><b>Sent:</b> Wednesday, August 15, 2012 1:30 PM<br><b>To:</b> Edward Crabbe; Alia Atlas<br><b>Cc:</b> David Lake (dlake); [email-masked]<br><b>Subject:</b> Re: [irs-discuss] IRS comments<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks.&nbsp; Can you also give us what you mean by &#8220;controller&#8221;.&nbsp; <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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Olen<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><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"'> Edward Crabbe <a href="mailto:[mailto:[email-masked]]">[mailto:[email-masked]]</a> <br><b>Sent:</b> Wednesday, August 15, 2012 1:24 PM<br><b>To:</b> Alia Atlas<br><b>Cc:</b> David Lake (dlake); Olen Stokes; <a href="mailto:[email-masked]">[email-masked]</a><br><b>Subject:</b> Re: [irs-discuss] IRS comments<o:p></o:p></span></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>s/wg/pre-BOF proto-wg :P/g &nbsp;<o:p></o:p></p><div><p class=MsoNormal>On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal>+1 Alia. &nbsp;There's been a lot of confusion over this term. &nbsp;Having gone a few rounds with folks on this one in other forums, I'll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc) &nbsp;that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<o:p></o:p></p><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>Having 'end user' applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg. &nbsp;<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>my 2c.&nbsp;<o:p></o:p></p></div><div><div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal>On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal>Hi David,<br><br>We do need to clarify what is meant by an application. &nbsp;I would not<br>expect that real user-land applications would talk directly to routing<br>devices via IRS. &nbsp;I can see that going through an intermediary. &nbsp;The<br>IRS abstractions are unlikely to be as high-level as user-land<br>applications would want and the security and policy issues would get<br>exciting.<br><br>Clarifying what applications are more in-scope initially is part of<br>where use-cases will help. &nbsp;Can you write up ones to<br>categorize/describe your thoughts?<br><span style='color:#888888'><br>Alia</span><o:p></o:p></p><div><div><p class=MsoNormal><br>On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>&gt;<br>&gt; Who is the target audience here ? &nbsp; That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>&gt;<br>&gt; This presently appears to be a little confused - at least in my mind. &nbsp;The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>&gt;<br>&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>&gt;<br>&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will &nbsp;need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser. &nbsp; How the stream traverses the infrastructure is immaterial.<br>&gt;<br>&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>&gt;<br>&gt; Thanks<br>&gt;<br>&gt; David<br>&gt;<br>&gt; -----Original Message-----<br>&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>&gt; To: Olen Stokes<br>&gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;<br>&gt; I have not specifically heard from application vendors about this.<br>&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets. &nbsp;Those can drive which subset of functionality we focus on.<br>&gt;<br>&gt; More use-cases are, of course, quite welcome. &nbsp;Posting them to the mailing list is a good first start. &nbsp;Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>&gt;<br>&gt; Alia<br>&gt;<br>&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot; &nbsp;should be?<br>&gt;&gt;<br>&gt;&gt; Olen<br>&gt;&gt;<br>&gt;&gt; -----Original Message-----<br>&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>&gt;&gt; To: Shah, Himanshu<br>&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>&gt;&gt; Alia Atlas; Scott Whyte<br>&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;<br>&gt;&gt; Hi Himanshu,<br>&gt;&gt;<br>&gt;&gt; Welcome. &nbsp; I agree that IRS isn't going to spring into being fully<br>&gt;&gt; formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>&gt;&gt;<br>&gt;&gt; Alia<br>&gt;&gt;<br>&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>&gt;&gt;&gt; We need to make sure that exposed interface to<br>&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc &nbsp;provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt; himanshu<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; -----Original Message-----<br>&gt;&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>&gt;&gt;&gt; To: Scott Whyte<br>&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ...snip...<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>&gt;&gt;&gt;&gt;&gt; on the device. &nbsp; Russ's suggestion that for the RIB sub-interface, the<br>&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions. &nbsp;Obviously, implementations<br>&gt;&gt;&gt;&gt;&gt; may differ.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree. &nbsp;Its not clear<br>&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>&gt;&gt;&gt;&gt; routing processes, if they so desire. &nbsp;OTOH if it can all be done<br>&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data. &nbsp;This is part of where having good use-cases will help us understand what behavior is necessary. &nbsp;The static &nbsp;routes do seem like a simpler case to start with.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Alia<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; irs-discuss mailing list<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt;&gt; _______________________________________________<br>&gt;&gt; irs-discuss mailing list<br>&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt; _______________________________________________<br>&gt; irs-discuss mailing list<br>&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>_______________________________________________<br>irs-discuss mailing list<br><a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></div></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
--_000_B37E6A2CE5957F4E83C1D9845A0FFE38014A33C0A0MDWEXGMB02cie_--

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 11:20:07 -0700
To: Olen Stokes <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--14dae93410c364e86604c751fc5d
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

The software (interacting with the 'applications' and) generating the
actual PDUs understood by the NEs.

On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes
<[email-masked]>wrote:

> Thanks.  Can you also give us what you mean by “controller”.  ****
>
> ** **
>
> Olen****
>
> ** **
>
> *From:* Edward Crabbe [mailto:[email-masked]]
> *Sent:* Wednesday, August 15, 2012 1:24 PM
> *To:* Alia Atlas
> *Cc:* David Lake (dlake); Olen Stokes; [email-masked]
>
> *Subject:* Re: [irs-discuss] IRS comments****
>
> ** **
>
> s/wg/pre-BOF proto-wg :P/g  ****
>
> On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:***
> *
>
> +1 Alia.  There's been a lot of confusion over this term.  Having gone a
> few rounds with folks on this one in other forums, I'll point out that what
> most people mean by application (myself included) is some set of control
> software (a scheduler, a path optimizer etc)  that provides instructions to
> the controller, which are in turn translated to the appropriate PDUs.****
>
> ** **
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds
> like a recipe for disaster for operational networks, or, as is more likely,
> a quick hike to the protocol grave yard (followed by a long grave-side
> party :P) for the wg.  ****
>
> ** **
>
> my 2c. ****
>
> ** **
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:****
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia****
>
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
> > As another newbie to this, I have some questions about "application
> vendors."
> >
> > Who is the target audience here ?   That will determine what
> functionality and abstraction of the network we need to expose to that
> "application."
> >
> > This presently appears to be a little confused - at least in my mind.
>  The draft talks very much as if the application we are addressing is an
> OSS/BSS system, essentially provisioning from the domain owner.
> >
> > However, linking this to the wider goals of SDN as voiced by
> customers/users at the first Open Network Summit, there appears to be a
> desire for cross-domain and user-land application integration.
> >
> > At this level - as an example giving a content cache the ability to
> ensure delivery of an HD video to an end user - the application will not be
> interested in the underlying topology of the network; it will  need to know
> that application X can be delivered with parameters Y between reading from
> the content store to delivery to the user's browser.   How the stream
> traverses the infrastructure is immaterial.
> >
> > Are we intending that IRS satisfies BOTH these requirements (i.e. for
> ALL applications ?), or should we be more prescriptive about which
> application space we are addressing ?
> >
> > Thanks
> >
> > David
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Alia Atlas
> > Sent: Wednesday, August 15, 2012 7:23 AM
> > To: Olen Stokes
> > Cc: [email-masked]
> > Subject: Re: [irs-discuss] IRS comments
> >
> > I have not specifically heard from application vendors about this.
> > My current plan is that we focus on a Use-Cases draft and define within
> that some motivating use-cases that we agree are good first targets.  Those
> can drive which subset of functionality we focus on.
> >
> > More use-cases are, of course, quite welcome.  Posting them to the
> mailing list is a good first start.  Russ White is starting the general
> use-cases draft based on the three use-cases that he sent to the list.
> >
> > Alia
> >
> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <
> [email-masked]> wrote:
> >> Are there applications vendors out there that already have specific
> requirements for what this " subset of the data-models for sub-interfaces"
>  should be?
> >>
> >> Olen
> >>
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >> Sent: Wednesday, August 15, 2012 9:08 AM
> >> To: Shah, Himanshu
> >> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
> >> Alia Atlas; Scott Whyte
> >> Subject: Re: [irs-discuss] IRS comments
> >>
> >> Hi Himanshu,
> >>
> >> Welcome.   I agree that IRS isn't going to spring into being fully
> >> formed - I expect that we'll focus on a subset of the data-models for
> sub-interfaces along with an associated protocol (whether that is a new one
> or extending an existing one).
> >>
> >> Alia
> >>
> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]>
> wrote:
> >>> Newbie to this discussions list and have read only a last couple of
> mails, so pardon the repeat if somebody has already raised the following as
> a concern.
> >>>
> >>> I realize we are early in IRS architecture definition but one thing to
> keep in mind is the user experience.
> >>> We need to make sure that exposed interface to
> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
> action/response/events even when different implementations has varying
> capabilities.
> >>>
> >>> At the moment it seems like a wild wild west.
> >>> Perhaps IRS can be defined in phases starting with a simpler, limited
> version..
> >>>
> >>> Thanks,
> >>> himanshu
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >>> Sent: Monday, August 13, 2012 8:41 AM
> >>> To: Scott Whyte
> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
> >>> [email-masked]
> >>> Subject: Re: [irs-discuss] IRS comments
> >>>
> >>> ...snip...
> >>>
> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]>
> wrote:
> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]>
> wrote:
> >>>
> >>>>> I do think it is important to have the RIB as an arbitration
> mechanism
> >>>>> on the device.   Russ's suggestion that for the RIB sub-interface,
> the
> >>>>> IRS agent might communicate logically to an IRS routing process
> >>>>> gives good semantics and interactions.  Obviously, implementations
> >>>>> may differ.
> >>>>
> >>>> As long as the arbitration mechanism is reconfigurable by the
> >>>> operator to whatever precedence they want, I agree.  Its not clear
> >>>> to me if various RIB implementations treat all proffered routes the
> >>>> same, nor if they store the same meta-data with all protocol sources.
> >>>> So there needs to be some way for the operator to leverage exposed
> >>>> protocol-specific optimizations, without conflict from the other
> >>>> routing processes, if they so desire.  OTOH if it can all be done
> >>>> via static routes, it seems much simpler. :)
> >>>
> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define
> the different precedences; my assumption is that it would be per route with
> a well-defined small set of meta-data.  This is part of where having good
> use-cases will help us understand what behavior is necessary.  The static
>  routes do seem like a simpler case to start with.
> >>>
> >>> Alia
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> > _______________________________________________
> > irs-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
> ** **
>
> ** **
>

--14dae93410c364e86604c751fc5d
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

The software (interacting with the &#39;applications&#39; and) generating the actual PDUs understood by the NEs. <div><br><div class="gmail_quote">On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <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"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Thanks.  Can you also give us what you mean by “controller”.  <u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d">Olen<u></u><u></u></span></p>

<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1f497d"><u></u> <u></u></span></p><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;"> Edward Crabbe [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] <br>

<b>Sent:</b> Wednesday, August 15, 2012 1:24 PM<br><b>To:</b> Alia Atlas<br><b>Cc:</b> David Lake (dlake); Olen Stokes; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a></span></p><div><div class="h5">

<br><b>Subject:</b> Re: [irs-discuss] IRS comments<u></u><u></u></div></div><p></p><div><div class="h5"><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal" style="margin-bottom:12.0pt">s/wg/pre-BOF proto-wg :P/g  <u></u><u></u></p>

<div><p class="MsoNormal">On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></p><p class="MsoNormal">+1 Alia.  There&#39;s been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I&#39;ll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<u></u><u></u></p>

<div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Having &#39;end user&#39; applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.  <u></u><u></u></p>

</div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">my 2c. <u></u><u></u></p></div><div><div><div><p class="MsoNormal"><u></u> <u></u></p><div><p class="MsoNormal">On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<u></u><u></u></p>

<p class="MsoNormal">Hi David,<br><br>We do need to clarify what is meant by an application.  I would not<br>expect that real user-land applications would talk directly to routing<br>devices via IRS.  I can see that going through an intermediary.  The<br>

IRS abstractions are unlikely to be as high-level as user-land<br>applications would want and the security and policy issues would get<br>exciting.<br><br>Clarifying what applications are more in-scope initially is part of<br>

where use-cases will help.  Can you write up ones to<br>categorize/describe your thoughts?<br><span style="color:#888888"><br>Alia</span><u></u><u></u></p><div><div><p class="MsoNormal"><br>On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>

&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>&gt;<br>&gt; Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>

&gt;<br>&gt; This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>

&gt;<br>&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>&gt;<br>
&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user&#39;s browser.   How the stream traverses the infrastructure is immaterial.<br>

&gt;<br>&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>&gt;<br>&gt; Thanks<br>&gt;<br>

&gt; David<br>&gt;<br>&gt; -----Original Message-----<br>&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>&gt; To: Olen Stokes<br>&gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;<br>
&gt; I have not specifically heard from application vendors about this.<br>
&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.<br>&gt;<br>&gt; More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>

&gt;<br>&gt; Alia<br>&gt;<br>&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot;  should be?<br>

&gt;&gt;<br>&gt;&gt; Olen<br>&gt;&gt;<br>&gt;&gt; -----Original Message-----<br>&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>&gt;&gt; To: Shah, Himanshu<br>&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>

&gt;&gt; Alia Atlas; Scott Whyte<br>&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;<br>&gt;&gt; Hi Himanshu,<br>&gt;&gt;<br>&gt;&gt; Welcome.   I agree that IRS isn&#39;t going to spring into being fully<br>
&gt;&gt; formed - I expect that we&#39;ll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>
&gt;&gt;<br>&gt;&gt; Alia<br>&gt;&gt;<br>&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>&gt;&gt;&gt; We need to make sure that exposed interface to<br>&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt; himanshu<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; -----Original Message-----<br>&gt;&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>&gt;&gt;&gt; To: Scott Whyte<br>&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ...snip...<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>

&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>

&gt;&gt;&gt;&gt;&gt; on the device.   Russ&#39;s suggestion that for the RIB sub-interface, the<br>&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions.  Obviously, implementations<br>

&gt;&gt;&gt;&gt;&gt; may differ.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree.  Its not clear<br>

&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>

&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>&gt;&gt;&gt;&gt; routing processes, if they so desire.  OTOH if it can all be done<br>&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.<br>

&gt;&gt;&gt;<br>&gt;&gt;&gt; Alia<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; irs-discuss mailing list<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>

&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt;&gt; _______________________________________________<br>&gt;&gt; irs-discuss mailing list<br>

&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>

&gt; _______________________________________________<br>&gt; irs-discuss mailing list<br>&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>

_______________________________________________<br>irs-discuss mailing list<br><a href="mailto:[email-masked]" target="_blank">[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><u></u><u></u></p>

</div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div></div></div></blockquote></div><br></div>

--14dae93410c364e86604c751fc5d--

Date: Wed, 15 Aug 2012 13:48:58 -0400
From: Alia Atlas <[email-masked]>
To: "David Lake (dlake)" <[email-masked]>
Cc: Olen Stokes <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Sounds good.  Let me know if/when you'd like me to review it.

Alia

On Wed, Aug 15, 2012 at 1:38 PM, David Lake (dlake) <[email-masked]> wrote:
> HI Alia
>
> OK - I'll work on a user-land use-case, and we'll try and factor where IRS sits.
>
> I think that will definitely help define which applications IRS is relevant for, and maybe give pointers to where additional work could be applied.
>
> Thanks !
>
> David
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 10:36 AM
> To: David Lake (dlake)
> Cc: Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> Hi David,
>
> I agree that the abstractions that are appropriate for a higher layer application are probably not those appropriate for IRS, where some understanding of the routing system, learnt topology, etc, are appropriate.
>
> If we do it right, the IRS protocol might be able to work with different data-models representing those - but I think considering such data-models is quite out-of-scope.  Let's let IRS get real legs and definition.  I don't think it makes sense to fold those requirements and use-cases into IRS - even though the same protocol might eventually suffice.
>
> That said, if you have a model where there's an intermediary (where orchestrator, service-specific app, controller, etc) that can do the translation, such use-cases would be of interest.  I'm certainly interested in verifying that top-down use-cases can connect up with the information and controls that IRS is intended to provide.
>
> Alia
>
> On Wed, Aug 15, 2012 at 1:11 PM, David Lake (dlake) <[email-masked]> wrote:
>> Hi Alia
>>
>> I already have some use-cases in mind for network service delivery and I'll work on writing them up.
>>
>> It does appear that the application that the current IRS draft refers to is management and provisioning within the SP domain.  Whilst I agree that these are areas in need to standardisation and enhancement, this could be seen as a sub-set of the wider application integration to the transport layer that is needed - a use-case, if you will.
>>
>> The underlying principles of IRS as put out in the draft does appear to provide an extensible, scalable protocol that would appeal to generic application providers - what will be key is to ensure that the primitives provided to/from the application are relevant and in terms that an application provider would understand.   It is unlikely that the nuances of routing will be of any interest to most applications.
>>
>> One possible solution to this is to create another protocol similar and related to IRS that represents the entirety of the transport infrastructure between content and consumer in terms that are relevant to the application.   However, I want to avoid creating yet another layer with the associated RPC complexities - that will not assist with long-term adoption.
>>
>> So, I am wondering if IRS can become a more broad-based representative protocol with one defined use-case being the kind of lower-level RP integration that is currently envisaged ?
>>
>> David
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Wednesday, August 15, 2012 8:48 AM
>> To: David Lake (dlake)
>> Cc: Olen Stokes; [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not expect that real user-land applications would talk directly to routing devices via IRS.  I can see that going through an intermediary.  The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting.
>>
>> Clarifying what applications are more in-scope initially is part of where use-cases will help.  Can you write up ones to categorize/describe your thoughts?
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]> wrote:
>>> As another newbie to this, I have some questions about "application vendors."
>>>
>>> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>>>
>>> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>>>
>>> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>>>
>>> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>>>
>>> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>>>
>>> Thanks
>>>
>>> David
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 7:23 AM
>>> To: Olen Stokes
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> I have not specifically heard from application vendors about this.
>>> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>>>
>>> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]> wrote:
>>>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>>>
>>>> Olen
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>>> To: Shah, Himanshu
>>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>>> Nadeau; Alia Atlas; Scott Whyte
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> Hi Himanshu,
>>>>
>>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>>>
>>>> Alia
>>>>
>>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>>>
>>>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>>>> We need to make sure that exposed interface to
>>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>>>
>>>>> At the moment it seems like a wild wild west.
>>>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>>>
>>>>> Thanks,
>>>>> himanshu
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: [email-masked]
>>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>>> To: Scott Whyte
>>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>>> [email-masked]
>>>>> Subject: Re: [irs-discuss] IRS comments
>>>>>
>>>>> ...snip...
>>>>>
>>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>>
>>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>>> gives good semantics and interactions.  Obviously,
>>>>>>> implementations may differ.
>>>>>>
>>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>>> to me if various RIB implementations treat all proffered routes
>>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>>> So there needs to be some way for the operator to leverage exposed
>>>>>> protocol-specific optimizations, without conflict from the other
>>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>>> via static routes, it seems much simpler. :)
>>>>>
>>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>>>
>>>>> Alia
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "David Lake (dlake)" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 17:38:32 +0000
Accept-Language: en-US
Cc: Olen Stokes <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

HI Alia

OK - I'll work on a user-land use-case, and we'll try and factor where IRS sits.

I think that will definitely help define which applications IRS is relevant for, and maybe give pointers to where additional work could be applied.

Thanks !

David

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 10:36 AM
To: David Lake (dlake)
Cc: Olen Stokes; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Hi David,

I agree that the abstractions that are appropriate for a higher layer application are probably not those appropriate for IRS, where some understanding of the routing system, learnt topology, etc, are appropriate.

If we do it right, the IRS protocol might be able to work with different data-models representing those - but I think considering such data-models is quite out-of-scope.  Let's let IRS get real legs and definition.  I don't think it makes sense to fold those requirements and use-cases into IRS - even though the same protocol might eventually suffice.

That said, if you have a model where there's an intermediary (where orchestrator, service-specific app, controller, etc) that can do the translation, such use-cases would be of interest.  I'm certainly interested in verifying that top-down use-cases can connect up with the information and controls that IRS is intended to provide.

Alia

On Wed, Aug 15, 2012 at 1:11 PM, David Lake (dlake) <[email-masked]> wrote:
> Hi Alia
>
> I already have some use-cases in mind for network service delivery and I'll work on writing them up.
>
> It does appear that the application that the current IRS draft refers to is management and provisioning within the SP domain.  Whilst I agree that these are areas in need to standardisation and enhancement, this could be seen as a sub-set of the wider application integration to the transport layer that is needed - a use-case, if you will.
>
> The underlying principles of IRS as put out in the draft does appear to provide an extensible, scalable protocol that would appeal to generic application providers - what will be key is to ensure that the primitives provided to/from the application are relevant and in terms that an application provider would understand.   It is unlikely that the nuances of routing will be of any interest to most applications.
>
> One possible solution to this is to create another protocol similar and related to IRS that represents the entirety of the transport infrastructure between content and consumer in terms that are relevant to the application.   However, I want to avoid creating yet another layer with the associated RPC complexities - that will not assist with long-term adoption.
>
> So, I am wondering if IRS can become a more broad-based representative protocol with one defined use-case being the kind of lower-level RP integration that is currently envisaged ?
>
> David
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 8:48 AM
> To: David Lake (dlake)
> Cc: Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not expect that real user-land applications would talk directly to routing devices via IRS.  I can see that going through an intermediary.  The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting.
>
> Clarifying what applications are more in-scope initially is part of where use-cases will help.  Can you write up ones to categorize/describe your thoughts?
>
> Alia
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]> wrote:
>> As another newbie to this, I have some questions about "application vendors."
>>
>> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]> wrote:
>>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas 
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to 
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process 
>>>>>> gives good semantics and interactions.  Obviously, 
>>>>>> implementations may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the 
>>>>> operator to whatever precedence they want, I agree.  Its not clear 
>>>>> to me if various RIB implementations treat all proffered routes 
>>>>> the same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed 
>>>>> protocol-specific optimizations, without conflict from the other 
>>>>> routing processes, if they so desire.  OTOH if it can all be done 
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 13:36:56 -0400
From: Alia Atlas <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: Olen Stokes <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Want to write up a good clear definition to put in the problem-statement?
I think that Chris Liljenstolpe is also working on that...

Alia

On Wed, Aug 15, 2012 at 1:22 PM, Edward Crabbe <[email-masked]> wrote:
> +1 Alia.  There's been a lot of confusion over this term.  Having gone a few
> rounds with folks on this one in other forums, I'll point out that what most
> people mean by application (myself included) is some set of control software
> (a scheduler, a path optimizer etc)  that provides instructions to the
> controller, which are in turn translated to the appropriate PDUs.
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds like
> a recipe for disaster for operational networks, or, as is more likely, a
> quick hike to the protocol grave yard (followed by a long grave-side party
> :P) for the wg.
>
> my 2c.
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to routing
>> devices via IRS.  I can see that going through an intermediary.  The
>> IRS abstractions are unlikely to be as high-level as user-land
>> applications would want and the security and policy issues would get
>> exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
>> wrote:
>> > As another newbie to this, I have some questions about "application
>> > vendors."
>> >
>> > Who is the target audience here ?   That will determine what
>> > functionality and abstraction of the network we need to expose to that
>> > "application."
>> >
>> > This presently appears to be a little confused - at least in my mind.
>> > The draft talks very much as if the application we are addressing is an
>> > OSS/BSS system, essentially provisioning from the domain owner.
>> >
>> > However, linking this to the wider goals of SDN as voiced by
>> > customers/users at the first Open Network Summit, there appears to be a
>> > desire for cross-domain and user-land application integration.
>> >
>> > At this level - as an example giving a content cache the ability to
>> > ensure delivery of an HD video to an end user - the application will not be
>> > interested in the underlying topology of the network; it will  need to know
>> > that application X can be delivered with parameters Y between reading from
>> > the content store to delivery to the user's browser.   How the stream
>> > traverses the infrastructure is immaterial.
>> >
>> > Are we intending that IRS satisfies BOTH these requirements (i.e. for
>> > ALL applications ?), or should we be more prescriptive about which
>> > application space we are addressing ?
>> >
>> > Thanks
>> >
>> > David
>> >
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]]
>> > On Behalf Of Alia Atlas
>> > Sent: Wednesday, August 15, 2012 7:23 AM
>> > To: Olen Stokes
>> > Cc: [email-masked]
>> > Subject: Re: [irs-discuss] IRS comments
>> >
>> > I have not specifically heard from application vendors about this.
>> > My current plan is that we focus on a Use-Cases draft and define within
>> > that some motivating use-cases that we agree are good first targets.  Those
>> > can drive which subset of functionality we focus on.
>> >
>> > More use-cases are, of course, quite welcome.  Posting them to the
>> > mailing list is a good first start.  Russ White is starting the general
>> > use-cases draft based on the three use-cases that he sent to the list.
>> >
>> > Alia
>> >
>> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
>> > <[email-masked]> wrote:
>> >> Are there applications vendors out there that already have specific
>> >> requirements for what this " subset of the data-models for sub-interfaces"
>> >> should be?
>> >>
>> >> Olen
>> >>
>> >> -----Original Message-----
>> >> From: [email-masked]
>> >> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> >> Sent: Wednesday, August 15, 2012 9:08 AM
>> >> To: Shah, Himanshu
>> >> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
>> >> Alia Atlas; Scott Whyte
>> >> Subject: Re: [irs-discuss] IRS comments
>> >>
>> >> Hi Himanshu,
>> >>
>> >> Welcome.   I agree that IRS isn't going to spring into being fully
>> >> formed - I expect that we'll focus on a subset of the data-models for
>> >> sub-interfaces along with an associated protocol (whether that is a new one
>> >> or extending an existing one).
>> >>
>> >> Alia
>> >>
>> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]>
>> >> wrote:
>> >>> Newbie to this discussions list and have read only a last couple of
>> >>> mails, so pardon the repeat if somebody has already raised the following as
>> >>> a concern.
>> >>>
>> >>> I realize we are early in IRS architecture definition but one thing to
>> >>> keep in mind is the user experience.
>> >>> We need to make sure that exposed interface to
>> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
>> >>> action/response/events even when different implementations has varying
>> >>> capabilities.
>> >>>
>> >>> At the moment it seems like a wild wild west.
>> >>> Perhaps IRS can be defined in phases starting with a simpler, limited
>> >>> version..
>> >>>
>> >>> Thanks,
>> >>> himanshu
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: [email-masked]
>> >>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> >>> Sent: Monday, August 13, 2012 8:41 AM
>> >>> To: Scott Whyte
>> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>> >>> [email-masked]
>> >>> Subject: Re: [irs-discuss] IRS comments
>> >>>
>> >>> ...snip...
>> >>>
>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]>
>> >>> wrote:
>> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]>
>> >>>> wrote:
>> >>>
>> >>>>> I do think it is important to have the RIB as an arbitration
>> >>>>> mechanism
>> >>>>> on the device.   Russ's suggestion that for the RIB sub-interface,
>> >>>>> the
>> >>>>> IRS agent might communicate logically to an IRS routing process
>> >>>>> gives good semantics and interactions.  Obviously, implementations
>> >>>>> may differ.
>> >>>>
>> >>>> As long as the arbitration mechanism is reconfigurable by the
>> >>>> operator to whatever precedence they want, I agree.  Its not clear
>> >>>> to me if various RIB implementations treat all proffered routes the
>> >>>> same, nor if they store the same meta-data with all protocol sources.
>> >>>> So there needs to be some way for the operator to leverage exposed
>> >>>> protocol-specific optimizations, without conflict from the other
>> >>>> routing processes, if they so desire.  OTOH if it can all be done
>> >>>> via static routes, it seems much simpler. :)
>> >>>
>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>> >>> the different precedences; my assumption is that it would be per route with
>> >>> a well-defined small set of meta-data.  This is part of where having good
>> >>> use-cases will help us understand what behavior is necessary.  The static
>> >>> routes do seem like a simpler case to start with.
>> >>>
>> >>> Alia
>> >>> _______________________________________________
>> >>> irs-discuss mailing list
>> >>> [email-masked]
>> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> >> _______________________________________________
>> >> irs-discuss mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>> > _______________________________________________
>> > irs-discuss mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

Date: Wed, 15 Aug 2012 13:36:03 -0400
From: Alia Atlas <[email-masked]>
To: "David Lake (dlake)" <[email-masked]>
Cc: Olen Stokes <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Hi David,

I agree that the abstractions that are appropriate for a higher layer
application are probably not those appropriate for IRS, where some
understanding of the routing system, learnt topology, etc, are
appropriate.

If we do it right, the IRS protocol might be able to work with
different data-models representing those - but I think considering
such data-models is quite out-of-scope.  Let's let IRS get real legs
and definition.  I don't think it makes sense to fold those
requirements and use-cases into IRS - even though the same protocol
might eventually suffice.

That said, if you have a model where there's an intermediary (where
orchestrator, service-specific app, controller, etc) that can do the
translation, such use-cases would be of interest.  I'm certainly
interested in verifying that top-down use-cases can connect up with
the information and controls that IRS is intended to provide.

Alia

On Wed, Aug 15, 2012 at 1:11 PM, David Lake (dlake) <[email-masked]> wrote:
> Hi Alia
>
> I already have some use-cases in mind for network service delivery and I'll work on writing them up.
>
> It does appear that the application that the current IRS draft refers to is management and provisioning within the SP domain.  Whilst I agree that these are areas in need to standardisation and enhancement, this could be seen as a sub-set of the wider application integration to the transport layer that is needed - a use-case, if you will.
>
> The underlying principles of IRS as put out in the draft does appear to provide an extensible, scalable protocol that would appeal to generic application providers - what will be key is to ensure that the primitives provided to/from the application are relevant and in terms that an application provider would understand.   It is unlikely that the nuances of routing will be of any interest to most applications.
>
> One possible solution to this is to create another protocol similar and related to IRS that represents the entirety of the transport infrastructure between content and consumer in terms that are relevant to the application.   However, I want to avoid creating yet another layer with the associated RPC complexities - that will not assist with long-term adoption.
>
> So, I am wondering if IRS can become a more broad-based representative protocol with one defined use-case being the kind of lower-level RP integration that is currently envisaged ?
>
> David
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 15, 2012 8:48 AM
> To: David Lake (dlake)
> Cc: Olen Stokes; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> Hi David,
>
> We do need to clarify what is meant by an application.  I would not expect that real user-land applications would talk directly to routing devices via IRS.  I can see that going through an intermediary.  The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting.
>
> Clarifying what applications are more in-scope initially is part of where use-cases will help.  Can you write up ones to categorize/describe your thoughts?
>
> Alia
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]> wrote:
>> As another newbie to this, I have some questions about "application vendors."
>>
>> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>>
>> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>>
>> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>>
>> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>>
>> Thanks
>>
>> David
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 7:23 AM
>> To: Olen Stokes
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> I have not specifically heard from application vendors about this.
>> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>>
>> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]> wrote:
>>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>>
>>> Olen
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Wednesday, August 15, 2012 9:08 AM
>>> To: Shah, Himanshu
>>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas
>>> Nadeau; Alia Atlas; Scott Whyte
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> Hi Himanshu,
>>>
>>> Welcome.   I agree that IRS isn't going to spring into being fully
>>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>>
>>> Alia
>>>
>>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>>
>>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>>> We need to make sure that exposed interface to
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>>
>>>> At the moment it seems like a wild wild west.
>>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>>
>>>> Thanks,
>>>> himanshu
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked]
>>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>>> Sent: Monday, August 13, 2012 8:41 AM
>>>> To: Scott Whyte
>>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>>> [email-masked]
>>>> Subject: Re: [irs-discuss] IRS comments
>>>>
>>>> ...snip...
>>>>
>>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>>
>>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>>> IRS agent might communicate logically to an IRS routing process
>>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>>> may differ.
>>>>>
>>>>> As long as the arbitration mechanism is reconfigurable by the
>>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>>> to me if various RIB implementations treat all proffered routes the
>>>>> same, nor if they store the same meta-data with all protocol sources.
>>>>> So there needs to be some way for the operator to leverage exposed
>>>>> protocol-specific optimizations, without conflict from the other
>>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>>> via static routes, it seems much simpler. :)
>>>>
>>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>>
>>>> Alia
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Olen Stokes <[email-masked]>
To: Edward Crabbe <[email-masked]>, Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 10:30:21 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

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

Thanks.  Can you also give us what you mean by "controller".

Olen

From: Edward Crabbe [mailto:[email-masked]]
Sent: Wednesday, August 15, 2012 1:24 PM
To: Alia Atlas
Cc: David Lake (dlake); Olen Stokes; [email-masked]
Subject: Re: [irs-discuss] IRS comments

s/wg/pre-BOF proto-wg :P/g
On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]<mailto:[email-masked]>> wrote:
+1 Alia.  There's been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I'll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.

Having 'end user' applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.

my 2c.

On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
Hi David,

We do need to clarify what is meant by an application.  I would not
expect that real user-land applications would talk directly to routing
devices via IRS.  I can see that going through an intermediary.  The
IRS abstractions are unlikely to be as high-level as user-land
applications would want and the security and policy issues would get
exciting.

Clarifying what applications are more in-scope initially is part of
where use-cases will help.  Can you write up ones to
categorize/describe your thoughts?

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]<mailto:[email-masked]>> wrote:
> As another newbie to this, I have some questions about "application vendors."
>
> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>
> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: [email-masked]<mailto:[email-masked]>
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>
> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]<mailto:[email-masked]>> wrote:
>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>
>> Olen
>>
>> -----Original Message-----
>> From: [email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: Gert Grammel; [email-masked]<mailto:[email-masked]>; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>>
>> Welcome.   I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]<mailto:[email-masked]>> wrote:
>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>> We need to make sure that exposed interface to
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.
>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>
>>> Thanks,
>>> himanshu
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]<mailto:[email-masked]>
>>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>> [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]<mailto:[email-masked]>> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>> IRS agent might communicate logically to an IRS routing process
>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>> may differ.
>>>>
>>>> As long as the arbitration mechanism is reconfigurable by the
>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>> to me if various RIB implementations treat all proffered routes the
>>>> same, nor if they store the same meta-data with all protocol sources.
>>>> So there needs to be some way for the operator to leverage exposed
>>>> protocol-specific optimizations, without conflict from the other
>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>> via static routes, it seems much simpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>
>>> Alia
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847USEXCHANGEc_
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: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;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-family:"Calibri","sans-serif";}
@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'>Thanks.&nbsp; Can you also give us what you mean by &#8220;controller&#8221;.&nbsp; <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><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Olen<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><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"'> Edward Crabbe [mailto:[email-masked]] <br><b>Sent:</b> Wednesday, August 15, 2012 1:24 PM<br><b>To:</b> Alia Atlas<br><b>Cc:</b> David Lake (dlake); Olen Stokes; [email-masked]<br><b>Subject:</b> Re: [irs-discuss] IRS comments<o:p></o:p></span></p><p class=MsoNormal><o:p>&nbsp;</o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'>s/wg/pre-BOF proto-wg :P/g &nbsp;<o:p></o:p></p><div><p class=MsoNormal>On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal>+1 Alia. &nbsp;There's been a lot of confusion over this term. &nbsp;Having gone a few rounds with folks on this one in other forums, I'll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc) &nbsp;that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<o:p></o:p></p><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>Having 'end user' applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg. &nbsp;<o:p></o:p></p></div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div><div><p class=MsoNormal>my 2c.&nbsp;<o:p></o:p></p></div><div><div><div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal>On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p><p class=MsoNormal>Hi David,<br><br>We do need to clarify what is meant by an application. &nbsp;I would not<br>expect that real user-land applications would talk directly to routing<br>devices via IRS. &nbsp;I can see that going through an intermediary. &nbsp;The<br>IRS abstractions are unlikely to be as high-level as user-land<br>applications would want and the security and policy issues would get<br>exciting.<br><br>Clarifying what applications are more in-scope initially is part of<br>where use-cases will help. &nbsp;Can you write up ones to<br>categorize/describe your thoughts?<br><span style='color:#888888'><br>Alia</span><o:p></o:p></p><div><div><p class=MsoNormal><br>On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>&gt;<br>&gt; Who is the target audience here ? &nbsp; That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>&gt;<br>&gt; This presently appears to be a little confused - at least in my mind. &nbsp;The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>&gt;<br>&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>&gt;<br>&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will &nbsp;need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser. &nbsp; How the stream traverses the infrastructure is immaterial.<br>&gt;<br>&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>&gt;<br>&gt; Thanks<br>&gt;<br>&gt; David<br>&gt;<br>&gt; -----Original Message-----<br>&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>&gt; To: Olen Stokes<br>&gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;<br>&gt; I have not specifically heard from application vendors about this.<br>&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets. &nbsp;Those can drive which subset of functionality we focus on.<br>&gt;<br>&gt; More use-cases are, of course, quite welcome. &nbsp;Posting them to the mailing list is a good first start. &nbsp;Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>&gt;<br>&gt; Alia<br>&gt;<br>&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot; &nbsp;should be?<br>&gt;&gt;<br>&gt;&gt; Olen<br>&gt;&gt;<br>&gt;&gt; -----Original Message-----<br>&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>&gt;&gt; To: Shah, Himanshu<br>&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>&gt;&gt; Alia Atlas; Scott Whyte<br>&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;<br>&gt;&gt; Hi Himanshu,<br>&gt;&gt;<br>&gt;&gt; Welcome. &nbsp; I agree that IRS isn't going to spring into being fully<br>&gt;&gt; formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>&gt;&gt;<br>&gt;&gt; Alia<br>&gt;&gt;<br>&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>&gt;&gt;&gt; We need to make sure that exposed interface to<br>&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc &nbsp;provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Thanks,<br>&gt;&gt;&gt; himanshu<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; -----Original Message-----<br>&gt;&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>&gt;&gt;&gt; To: Scott Whyte<br>&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; ...snip...<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>&gt;&gt;&gt;&gt;&gt; on the device. &nbsp; Russ's suggestion that for the RIB sub-interface, the<br>&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions. &nbsp;Obviously, implementations<br>&gt;&gt;&gt;&gt;&gt; may differ.<br>&gt;&gt;&gt;&gt;<br>&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree. &nbsp;Its not clear<br>&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>&gt;&gt;&gt;&gt; routing processes, if they so desire. &nbsp;OTOH if it can all be done<br>&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data. &nbsp;This is part of where having good use-cases will help us understand what behavior is necessary. &nbsp;The static &nbsp;routes do seem like a simpler case to start with.<br>&gt;&gt;&gt;<br>&gt;&gt;&gt; Alia<br>&gt;&gt;&gt; _______________________________________________<br>&gt;&gt;&gt; irs-discuss mailing list<br>&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt;&gt; _______________________________________________<br>&gt;&gt; irs-discuss mailing list<br>&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>&gt; _______________________________________________<br>&gt; irs-discuss mailing list<br>&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>_______________________________________________<br>irs-discuss mailing list<br><a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></p></div></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></div></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p></div></body></html>
--_000_A3C4E51A53661B4EBEE7C5F5E6FCDEB5025AB94FE847USEXCHANGEc_--

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 10:24:22 -0700
To: Alia Atlas <[email-masked]>
Cc: Olen Stokes <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--f46d0447882f071ba104c751355f
Content-Type: text/plain; charset=ISO-8859-1

s/wg/pre-BOF proto-wg :P/g

On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <[email-masked]> wrote:

> +1 Alia.  There's been a lot of confusion over this term.  Having gone a
> few rounds with folks on this one in other forums, I'll point out that what
> most people mean by application (myself included) is some set of control
> software (a scheduler, a path optimizer etc)  that provides instructions to
> the controller, which are in turn translated to the appropriate PDUs.
>
> Having 'end user' applications request/make changes to forwarding state
> without an intermediate broker/aggregator acting on their behalf sounds
> like a recipe for disaster for operational networks, or, as is more likely,
> a quick hike to the protocol grave yard (followed by a long grave-side
> party :P) for the wg.
>
> my 2c.
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:
>
>> Hi David,
>>
>> We do need to clarify what is meant by an application.  I would not
>> expect that real user-land applications would talk directly to routing
>> devices via IRS.  I can see that going through an intermediary.  The
>> IRS abstractions are unlikely to be as high-level as user-land
>> applications would want and the security and policy issues would get
>> exciting.
>>
>> Clarifying what applications are more in-scope initially is part of
>> where use-cases will help.  Can you write up ones to
>> categorize/describe your thoughts?
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
>> wrote:
>> > As another newbie to this, I have some questions about "application
>> vendors."
>> >
>> > Who is the target audience here ?   That will determine what
>> functionality and abstraction of the network we need to expose to that
>> "application."
>> >
>> > This presently appears to be a little confused - at least in my mind.
>>  The draft talks very much as if the application we are addressing is an
>> OSS/BSS system, essentially provisioning from the domain owner.
>> >
>> > However, linking this to the wider goals of SDN as voiced by
>> customers/users at the first Open Network Summit, there appears to be a
>> desire for cross-domain and user-land application integration.
>> >
>> > At this level - as an example giving a content cache the ability to
>> ensure delivery of an HD video to an end user - the application will not be
>> interested in the underlying topology of the network; it will  need to know
>> that application X can be delivered with parameters Y between reading from
>> the content store to delivery to the user's browser.   How the stream
>> traverses the infrastructure is immaterial.
>> >
>> > Are we intending that IRS satisfies BOTH these requirements (i.e. for
>> ALL applications ?), or should we be more prescriptive about which
>> application space we are addressing ?
>> >
>> > Thanks
>> >
>> > David
>> >
>> > -----Original Message-----
>> > From: [email-masked] [mailto:[email-masked]]
>> On Behalf Of Alia Atlas
>> > Sent: Wednesday, August 15, 2012 7:23 AM
>> > To: Olen Stokes
>> > Cc: [email-masked]
>> > Subject: Re: [irs-discuss] IRS comments
>> >
>> > I have not specifically heard from application vendors about this.
>> > My current plan is that we focus on a Use-Cases draft and define within
>> that some motivating use-cases that we agree are good first targets.  Those
>> can drive which subset of functionality we focus on.
>> >
>> > More use-cases are, of course, quite welcome.  Posting them to the
>> mailing list is a good first start.  Russ White is starting the general
>> use-cases draft based on the three use-cases that he sent to the list.
>> >
>> > Alia
>> >
>> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <
>> [email-masked]> wrote:
>> >> Are there applications vendors out there that already have specific
>> requirements for what this " subset of the data-models for sub-interfaces"
>>  should be?
>> >>
>> >> Olen
>> >>
>> >> -----Original Message-----
>> >> From: [email-masked]
>> >> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> >> Sent: Wednesday, August 15, 2012 9:08 AM
>> >> To: Shah, Himanshu
>> >> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
>> >> Alia Atlas; Scott Whyte
>> >> Subject: Re: [irs-discuss] IRS comments
>> >>
>> >> Hi Himanshu,
>> >>
>> >> Welcome.   I agree that IRS isn't going to spring into being fully
>> >> formed - I expect that we'll focus on a subset of the data-models for
>> sub-interfaces along with an associated protocol (whether that is a new one
>> or extending an existing one).
>> >>
>> >> Alia
>> >>
>> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]>
>> wrote:
>> >>> Newbie to this discussions list and have read only a last couple of
>> mails, so pardon the repeat if somebody has already raised the following as
>> a concern.
>> >>>
>> >>> I realize we are early in IRS architecture definition but one thing
>> to keep in mind is the user experience.
>> >>> We need to make sure that exposed interface to
>> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
>> action/response/events even when different implementations has varying
>> capabilities.
>> >>>
>> >>> At the moment it seems like a wild wild west.
>> >>> Perhaps IRS can be defined in phases starting with a simpler, limited
>> version..
>> >>>
>> >>> Thanks,
>> >>> himanshu
>> >>>
>> >>>
>> >>> -----Original Message-----
>> >>> From: [email-masked]
>> >>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> >>> Sent: Monday, August 13, 2012 8:41 AM
>> >>> To: Scott Whyte
>> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>> >>> [email-masked]
>> >>> Subject: Re: [irs-discuss] IRS comments
>> >>>
>> >>> ...snip...
>> >>>
>> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]>
>> wrote:
>> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]>
>> wrote:
>> >>>
>> >>>>> I do think it is important to have the RIB as an arbitration
>> mechanism
>> >>>>> on the device.   Russ's suggestion that for the RIB sub-interface,
>> the
>> >>>>> IRS agent might communicate logically to an IRS routing process
>> >>>>> gives good semantics and interactions.  Obviously, implementations
>> >>>>> may differ.
>> >>>>
>> >>>> As long as the arbitration mechanism is reconfigurable by the
>> >>>> operator to whatever precedence they want, I agree.  Its not clear
>> >>>> to me if various RIB implementations treat all proffered routes the
>> >>>> same, nor if they store the same meta-data with all protocol sources.
>> >>>> So there needs to be some way for the operator to leverage exposed
>> >>>> protocol-specific optimizations, without conflict from the other
>> >>>> routing processes, if they so desire.  OTOH if it can all be done
>> >>>> via static routes, it seems much simpler. :)
>> >>>
>> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define
>> the different precedences; my assumption is that it would be per route with
>> a well-defined small set of meta-data.  This is part of where having good
>> use-cases will help us understand what behavior is necessary.  The static
>>  routes do seem like a simpler case to start with.
>> >>>
>> >>> Alia
>> >>> _______________________________________________
>> >>> irs-discuss mailing list
>> >>> [email-masked]
>> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> >> _______________________________________________
>> >> irs-discuss mailing list
>> >> [email-masked]
>> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>> > _______________________________________________
>> > irs-discuss mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>
>

--f46d0447882f071ba104c751355f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

s/wg/pre-BOF proto-wg :P/g  <br><br><div class="gmail_quote">On Wed, Aug 15, 2012 at 10:22 AM, Edward Crabbe <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">

+1 Alia.  There&#39;s been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I&#39;ll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<div>

<br></div><div>Having &#39;end user&#39; applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.  </div>

<div><br></div><div>my 2c. </div><div class="HOEnZb"><div class="h5"><div><br><div class="gmail_quote">On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <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">Hi David,<br>
<br>
We do need to clarify what is meant by an application.  I would not<br>
expect that real user-land applications would talk directly to routing<br>
devices via IRS.  I can see that going through an intermediary.  The<br>
IRS abstractions are unlikely to be as high-level as user-land<br>
applications would want and the security and policy issues would get<br>
exciting.<br>
<br>
Clarifying what applications are more in-scope initially is part of<br>
where use-cases will help.  Can you write up ones to<br>
categorize/describe your thoughts?<br>
<span><font color="#888888"><br>
Alia<br>
</font></span><div><div><br>
On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>
&gt;<br>
&gt; Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>
&gt;<br>
&gt; This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>
&gt;<br>
&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>
&gt;<br>
&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user&#39;s browser.   How the stream traverses the infrastructure is immaterial.<br>

&gt;<br>
&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>
&gt;<br>
&gt; Thanks<br>
&gt;<br>
&gt; David<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a> [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>

&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>
&gt; To: Olen Stokes<br>
&gt; Cc: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt; Subject: Re: [irs-discuss] IRS comments<br>
&gt;<br>
&gt; I have not specifically heard from application vendors about this.<br>
&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.<br>
&gt;<br>
&gt; More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>
&gt;<br>
&gt; Alia<br>
&gt;<br>
&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot;  should be?<br>
&gt;&gt;<br>
&gt;&gt; Olen<br>
&gt;&gt;<br>
&gt;&gt; -----Original Message-----<br>
&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>
&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>
&gt;&gt; To: Shah, Himanshu<br>
&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>
&gt;&gt; Alia Atlas; Scott Whyte<br>
&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>
&gt;&gt;<br>
&gt;&gt; Hi Himanshu,<br>
&gt;&gt;<br>
&gt;&gt; Welcome.   I agree that IRS isn&#39;t going to spring into being fully<br>
&gt;&gt; formed - I expect that we&#39;ll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>
&gt;&gt;<br>
&gt;&gt; Alia<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>
&gt;&gt;&gt; We need to make sure that exposed interface to<br>
&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>
&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt; himanshu<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -----Original Message-----<br>
&gt;&gt;&gt; From: <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>] On Behalf Of Alia Atlas<br>
&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>
&gt;&gt;&gt; To: Scott Whyte<br>
&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>
&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ...snip...<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>
&gt;&gt;&gt;&gt;&gt; on the device.   Russ&#39;s suggestion that for the RIB sub-interface, the<br>
&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>
&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions.  Obviously, implementations<br>
&gt;&gt;&gt;&gt;&gt; may differ.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>
&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree.  Its not clear<br>
&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>
&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>
&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>
&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>
&gt;&gt;&gt;&gt; routing processes, if they so desire.  OTOH if it can all be done<br>
&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.<br>

&gt;&gt;&gt;<br>
&gt;&gt;&gt; Alia<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; irs-discuss mailing list<br>
&gt;&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; irs-discuss mailing list<br>
&gt;&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>
&gt; _______________________________________________<br>
&gt; irs-discuss mailing list<br>
&gt; <a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>
_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br>

--f46d0447882f071ba104c751355f--

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 10:22:42 -0700
To: Alia Atlas <[email-masked]>
Cc: Olen Stokes <[email-masked]>, "David Lake \(dlake\)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

--14dae9340e1b12973204c7512f9b
Content-Type: text/plain; charset=ISO-8859-1

+1 Alia.  There's been a lot of confusion over this term.  Having gone a
few rounds with folks on this one in other forums, I'll point out that what
most people mean by application (myself included) is some set of control
software (a scheduler, a path optimizer etc)  that provides instructions to
the controller, which are in turn translated to the appropriate PDUs.

Having 'end user' applications request/make changes to forwarding state
without an intermediate broker/aggregator acting on their behalf sounds
like a recipe for disaster for operational networks, or, as is more likely,
a quick hike to the protocol grave yard (followed by a long grave-side
party :P) for the wg.

my 2c.

On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:

> Hi David,
>
> We do need to clarify what is meant by an application.  I would not
> expect that real user-land applications would talk directly to routing
> devices via IRS.  I can see that going through an intermediary.  The
> IRS abstractions are unlikely to be as high-level as user-land
> applications would want and the security and policy issues would get
> exciting.
>
> Clarifying what applications are more in-scope initially is part of
> where use-cases will help.  Can you write up ones to
> categorize/describe your thoughts?
>
> Alia
>
> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]>
> wrote:
> > As another newbie to this, I have some questions about "application
> vendors."
> >
> > Who is the target audience here ?   That will determine what
> functionality and abstraction of the network we need to expose to that
> "application."
> >
> > This presently appears to be a little confused - at least in my mind.
>  The draft talks very much as if the application we are addressing is an
> OSS/BSS system, essentially provisioning from the domain owner.
> >
> > However, linking this to the wider goals of SDN as voiced by
> customers/users at the first Open Network Summit, there appears to be a
> desire for cross-domain and user-land application integration.
> >
> > At this level - as an example giving a content cache the ability to
> ensure delivery of an HD video to an end user - the application will not be
> interested in the underlying topology of the network; it will  need to know
> that application X can be delivered with parameters Y between reading from
> the content store to delivery to the user's browser.   How the stream
> traverses the infrastructure is immaterial.
> >
> > Are we intending that IRS satisfies BOTH these requirements (i.e. for
> ALL applications ?), or should we be more prescriptive about which
> application space we are addressing ?
> >
> > Thanks
> >
> > David
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Alia Atlas
> > Sent: Wednesday, August 15, 2012 7:23 AM
> > To: Olen Stokes
> > Cc: [email-masked]
> > Subject: Re: [irs-discuss] IRS comments
> >
> > I have not specifically heard from application vendors about this.
> > My current plan is that we focus on a Use-Cases draft and define within
> that some motivating use-cases that we agree are good first targets.  Those
> can drive which subset of functionality we focus on.
> >
> > More use-cases are, of course, quite welcome.  Posting them to the
> mailing list is a good first start.  Russ White is starting the general
> use-cases draft based on the three use-cases that he sent to the list.
> >
> > Alia
> >
> > On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <
> [email-masked]> wrote:
> >> Are there applications vendors out there that already have specific
> requirements for what this " subset of the data-models for sub-interfaces"
>  should be?
> >>
> >> Olen
> >>
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >> Sent: Wednesday, August 15, 2012 9:08 AM
> >> To: Shah, Himanshu
> >> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
> >> Alia Atlas; Scott Whyte
> >> Subject: Re: [irs-discuss] IRS comments
> >>
> >> Hi Himanshu,
> >>
> >> Welcome.   I agree that IRS isn't going to spring into being fully
> >> formed - I expect that we'll focus on a subset of the data-models for
> sub-interfaces along with an associated protocol (whether that is a new one
> or extending an existing one).
> >>
> >> Alia
> >>
> >> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]>
> wrote:
> >>> Newbie to this discussions list and have read only a last couple of
> mails, so pardon the repeat if somebody has already raised the following as
> a concern.
> >>>
> >>> I realize we are early in IRS architecture definition but one thing to
> keep in mind is the user experience.
> >>> We need to make sure that exposed interface to
> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
> action/response/events even when different implementations has varying
> capabilities.
> >>>
> >>> At the moment it seems like a wild wild west.
> >>> Perhaps IRS can be defined in phases starting with a simpler, limited
> version..
> >>>
> >>> Thanks,
> >>> himanshu
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked]
> >>> [mailto:[email-masked]] On Behalf Of Alia Atlas
> >>> Sent: Monday, August 13, 2012 8:41 AM
> >>> To: Scott Whyte
> >>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
> >>> [email-masked]
> >>> Subject: Re: [irs-discuss] IRS comments
> >>>
> >>> ...snip...
> >>>
> >>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]>
> wrote:
> >>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]>
> wrote:
> >>>
> >>>>> I do think it is important to have the RIB as an arbitration
> mechanism
> >>>>> on the device.   Russ's suggestion that for the RIB sub-interface,
> the
> >>>>> IRS agent might communicate logically to an IRS routing process
> >>>>> gives good semantics and interactions.  Obviously, implementations
> >>>>> may differ.
> >>>>
> >>>> As long as the arbitration mechanism is reconfigurable by the
> >>>> operator to whatever precedence they want, I agree.  Its not clear
> >>>> to me if various RIB implementations treat all proffered routes the
> >>>> same, nor if they store the same meta-data with all protocol sources.
> >>>> So there needs to be some way for the operator to leverage exposed
> >>>> protocol-specific optimizations, without conflict from the other
> >>>> routing processes, if they so desire.  OTOH if it can all be done
> >>>> via static routes, it seems much simpler. :)
> >>>
> >>> Clearly the IRS sub-interface for the RIB needs to introduce/define
> the different precedences; my assumption is that it would be per route with
> a well-defined small set of meta-data.  This is part of where having good
> use-cases will help us understand what behavior is necessary.  The static
>  routes do seem like a simpler case to start with.
> >>>
> >>> Alia
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> > _______________________________________________
> > irs-discuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

--14dae9340e1b12973204c7512f9b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1 Alia.  There&#39;s been a lot of confusion over this term.  Having gone a few rounds with folks on this one in other forums, I&#39;ll point out that what most people mean by application (myself included) is some set of control software (a scheduler, a path optimizer etc)  that provides instructions to the controller, which are in turn translated to the appropriate PDUs.<div>

<br></div><div>Having &#39;end user&#39; applications request/make changes to forwarding state without an intermediate broker/aggregator acting on their behalf sounds like a recipe for disaster for operational networks, or, as is more likely, a quick hike to the protocol grave yard (followed by a long grave-side party :P) for the wg.  </div>

<div><br></div><div>my 2c. </div><div><br><div class="gmail_quote">On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <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">Hi David,<br>
<br>
We do need to clarify what is meant by an application.  I would not<br>
expect that real user-land applications would talk directly to routing<br>
devices via IRS.  I can see that going through an intermediary.  The<br>
IRS abstractions are unlikely to be as high-level as user-land<br>
applications would want and the security and policy issues would get<br>
exciting.<br>
<br>
Clarifying what applications are more in-scope initially is part of<br>
where use-cases will help.  Can you write up ones to<br>
categorize/describe your thoughts?<br>
<span class="HOEnZb"><font color="#888888"><br>
Alia<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt; As another newbie to this, I have some questions about &quot;application vendors.&quot;<br>
&gt;<br>
&gt; Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that &quot;application.&quot;<br>
&gt;<br>
&gt; This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.<br>
&gt;<br>
&gt; However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.<br>
&gt;<br>
&gt; At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user&#39;s browser.   How the stream traverses the infrastructure is immaterial.<br>

&gt;<br>
&gt; Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?<br>
&gt;<br>
&gt; Thanks<br>
&gt;<br>
&gt; David<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: <a href="mailto:[email-masked]">[email-masked]</a> [mailto:<a href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Alia Atlas<br>
&gt; Sent: Wednesday, August 15, 2012 7:23 AM<br>
&gt; To: Olen Stokes<br>
&gt; Cc: <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt; Subject: Re: [irs-discuss] IRS comments<br>
&gt;<br>
&gt; I have not specifically heard from application vendors about this.<br>
&gt; My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.<br>
&gt;<br>
&gt; More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.<br>
&gt;<br>
&gt; Alia<br>
&gt;<br>
&gt; On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt; Are there applications vendors out there that already have specific requirements for what this &quot; subset of the data-models for sub-interfaces&quot;  should be?<br>
&gt;&gt;<br>
&gt;&gt; Olen<br>
&gt;&gt;<br>
&gt;&gt; -----Original Message-----<br>
&gt;&gt; From: <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; [mailto:<a href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Alia Atlas<br>
&gt;&gt; Sent: Wednesday, August 15, 2012 9:08 AM<br>
&gt;&gt; To: Shah, Himanshu<br>
&gt;&gt; Cc: Gert Grammel; <a href="mailto:[email-masked]">[email-masked]</a>; Lenny Giuliano; Thomas Nadeau;<br>
&gt;&gt; Alia Atlas; Scott Whyte<br>
&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>
&gt;&gt;<br>
&gt;&gt; Hi Himanshu,<br>
&gt;&gt;<br>
&gt;&gt; Welcome.   I agree that IRS isn&#39;t going to spring into being fully<br>
&gt;&gt; formed - I expect that we&#39;ll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).<br>
&gt;&gt;<br>
&gt;&gt; Alia<br>
&gt;&gt;<br>
&gt;&gt; On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;&gt; Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.<br>
&gt;&gt;&gt; We need to make sure that exposed interface to<br>
&gt;&gt;&gt; RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; At the moment it seems like a wild wild west.<br>
&gt;&gt;&gt; Perhaps IRS can be defined in phases starting with a simpler, limited version..<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thanks,<br>
&gt;&gt;&gt; himanshu<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; -----Original Message-----<br>
&gt;&gt;&gt; From: <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt;&gt; [mailto:<a href="mailto:[email-masked]">[email-masked]</a>] On Behalf Of Alia Atlas<br>
&gt;&gt;&gt; Sent: Monday, August 13, 2012 8:41 AM<br>
&gt;&gt;&gt; To: Scott Whyte<br>
&gt;&gt;&gt; Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;<br>
&gt;&gt;&gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt;&gt; Subject: Re: [irs-discuss] IRS comments<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ...snip...<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt; On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I do think it is important to have the RIB as an arbitration mechanism<br>
&gt;&gt;&gt;&gt;&gt; on the device.   Russ&#39;s suggestion that for the RIB sub-interface, the<br>
&gt;&gt;&gt;&gt;&gt; IRS agent might communicate logically to an IRS routing process<br>
&gt;&gt;&gt;&gt;&gt; gives good semantics and interactions.  Obviously, implementations<br>
&gt;&gt;&gt;&gt;&gt; may differ.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; As long as the arbitration mechanism is reconfigurable by the<br>
&gt;&gt;&gt;&gt; operator to whatever precedence they want, I agree.  Its not clear<br>
&gt;&gt;&gt;&gt; to me if various RIB implementations treat all proffered routes the<br>
&gt;&gt;&gt;&gt; same, nor if they store the same meta-data with all protocol sources.<br>
&gt;&gt;&gt;&gt; So there needs to be some way for the operator to leverage exposed<br>
&gt;&gt;&gt;&gt; protocol-specific optimizations, without conflict from the other<br>
&gt;&gt;&gt;&gt; routing processes, if they so desire.  OTOH if it can all be done<br>
&gt;&gt;&gt;&gt; via static routes, it seems much simpler. :)<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.<br>

&gt;&gt;&gt;<br>
&gt;&gt;&gt; Alia<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; irs-discuss mailing list<br>
&gt;&gt;&gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; irs-discuss mailing list<br>
&gt;&gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt;&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>
&gt; _______________________________________________<br>
&gt; irs-discuss mailing list<br>
&gt; <a href="mailto:[email-masked]">[email-masked]</a><br>
&gt; <a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</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>
</div></div></blockquote></div><br></div>

--14dae9340e1b12973204c7512f9b--

From: "David Lake (dlake)" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 17:11:55 +0000
Accept-Language: en-US
Cc: Olen Stokes <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Hi Alia

I already have some use-cases in mind for network service delivery and I'll work on writing them up.

It does appear that the application that the current IRS draft refers to is management and provisioning within the SP domain.  Whilst I agree that these are areas in need to standardisation and enhancement, this could be seen as a sub-set of the wider application integration to the transport layer that is needed - a use-case, if you will.

The underlying principles of IRS as put out in the draft does appear to provide an extensible, scalable protocol that would appeal to generic application providers - what will be key is to ensure that the primitives provided to/from the application are relevant and in terms that an application provider would understand.   It is unlikely that the nuances of routing will be of any interest to most applications. 

One possible solution to this is to create another protocol similar and related to IRS that represents the entirety of the transport infrastructure between content and consumer in terms that are relevant to the application.   However, I want to avoid creating yet another layer with the associated RPC complexities - that will not assist with long-term adoption.

So, I am wondering if IRS can become a more broad-based representative protocol with one defined use-case being the kind of lower-level RP integration that is currently envisaged ?

David

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 8:48 AM
To: David Lake (dlake)
Cc: Olen Stokes; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Hi David,

We do need to clarify what is meant by an application.  I would not expect that real user-land applications would talk directly to routing devices via IRS.  I can see that going through an intermediary.  The IRS abstractions are unlikely to be as high-level as user-land applications would want and the security and policy issues would get exciting.

Clarifying what applications are more in-scope initially is part of where use-cases will help.  Can you write up ones to categorize/describe your thoughts?

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]> wrote:
> As another newbie to this, I have some questions about "application vendors."
>
> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>
> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>
> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]> wrote:
>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>
>> Olen
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas 
>> Nadeau; Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>>
>> Welcome.   I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>> We need to make sure that exposed interface to 
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.
>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>
>>> Thanks,
>>> himanshu
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
>>> [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>
>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>> IRS agent might communicate logically to an IRS routing process 
>>>>> gives good semantics and interactions.  Obviously, implementations 
>>>>> may differ.
>>>>
>>>> As long as the arbitration mechanism is reconfigurable by the 
>>>> operator to whatever precedence they want, I agree.  Its not clear 
>>>> to me if various RIB implementations treat all proffered routes the 
>>>> same, nor if they store the same meta-data with all protocol sources.
>>>> So there needs to be some way for the operator to leverage exposed 
>>>> protocol-specific optimizations, without conflict from the other 
>>>> routing processes, if they so desire.  OTOH if it can all be done 
>>>> via static routes, it seems much simpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>
>>> Alia
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 22:29:23 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I agree. I saw your responses later and I think building strong use-cases first would help. I am looking more from an implementation perspective and thus interested to see what makes more realistic.  

Thanks,
Pranjal

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 15, 2012 9:50 AM
To: Dutta, Pranjal K (Pranjal)
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

This is why I want to focus on use-cases.  From there, I think we can
develop realistic requirements.   Feel free to contribute :-)

Alia

On Wed, Aug 15, 2012 at 12:47 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> +1. I am a newbie and have been observing the discussions so far. However it is not clear to me about the requirements. I think a sound approach is to solidify the requirements and then think about the solutions (APIs, the real-time transaction protocol etc).
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 6:43 AM
> To: Alia Atlas; Shah, Himanshu
> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
> Subject: Re: [irs-discuss] IRS comments
>
> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>
> Olen
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 9:08 AM
> To: Shah, Himanshu
> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
> Subject: Re: [irs-discuss] IRS comments
>
> Hi Himanshu,
>
> Welcome.   I agree that IRS isn't going to spring into being fully
> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>
> Alia
>
> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>
>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>> We need to make sure that exposed interface to
>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>
>> At the moment it seems like a wild wild west.
>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>
>> Thanks,
>> himanshu
>>
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Monday, August 13, 2012 8:41 AM
>> To: Scott Whyte
>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>> [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> ...snip...
>>
>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>
>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>> IRS agent might communicate logically to an IRS routing process
>>>> gives good semantics and interactions.  Obviously, implementations
>>>> may differ.
>>>
>>> As long as the arbitration mechanism is reconfigurable by the
>>> operator to whatever precedence they want, I agree.  Its not clear to
>>> me if various RIB implementations treat all proffered routes the
>>> same, nor if they store the same meta-data with all protocol sources.
>>> So there needs to be some way for the operator to leverage exposed
>>> protocol-specific optimizations, without conflict from the other
>>> routing processes, if they so desire.  OTOH if it can all be done via
>>> static routes, it seems much simpler. :)
>>
>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>
>> Alia
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 12:50:04 -0400
From: Alia Atlas <[email-masked]>
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

This is why I want to focus on use-cases.  From there, I think we can
develop realistic requirements.   Feel free to contribute :-)

Alia

On Wed, Aug 15, 2012 at 12:47 PM, Dutta, Pranjal K (Pranjal)
<[email-masked]> wrote:
> +1. I am a newbie and have been observing the discussions so far. However it is not clear to me about the requirements. I think a sound approach is to solidify the requirements and then think about the solutions (APIs, the real-time transaction protocol etc).
>
> Thanks,
> Pranjal
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Olen Stokes
> Sent: Wednesday, August 15, 2012 6:43 AM
> To: Alia Atlas; Shah, Himanshu
> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
> Subject: Re: [irs-discuss] IRS comments
>
> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>
> Olen
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 9:08 AM
> To: Shah, Himanshu
> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
> Subject: Re: [irs-discuss] IRS comments
>
> Hi Himanshu,
>
> Welcome.   I agree that IRS isn't going to spring into being fully
> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>
> Alia
>
> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>
>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>> We need to make sure that exposed interface to
>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>
>> At the moment it seems like a wild wild west.
>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>
>> Thanks,
>> himanshu
>>
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Monday, August 13, 2012 8:41 AM
>> To: Scott Whyte
>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>> [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> ...snip...
>>
>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>
>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>> IRS agent might communicate logically to an IRS routing process
>>>> gives good semantics and interactions.  Obviously, implementations
>>>> may differ.
>>>
>>> As long as the arbitration mechanism is reconfigurable by the
>>> operator to whatever precedence they want, I agree.  Its not clear to
>>> me if various RIB implementations treat all proffered routes the
>>> same, nor if they store the same meta-data with all protocol sources.
>>> So there needs to be some way for the operator to leverage exposed
>>> protocol-specific optimizations, without conflict from the other
>>> routing processes, if they so desire.  OTOH if it can all be done via
>>> static routes, it seems much simpler. :)
>>
>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>
>> Alia
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
To: Olen Stokes <[email-masked]>, Alia Atlas <[email-masked]>,  "Shah, Himanshu" <[email-masked]>
Date: Wed, 15 Aug 2012 22:17:40 +0530
Accept-Language: en-US
acceptlanguage: en-US
Cc: Gert Grammel <[email-masked]>, "[email-masked]" <[email-masked]>, Lenny Giuliano <[email-masked]>, Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, Scott Whyte <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

+1. I am a newbie and have been observing the discussions so far. However it is not clear to me about the requirements. I think a sound approach is to solidify the requirements and then think about the solutions (APIs, the real-time transaction protocol etc). 

Thanks,
Pranjal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Olen Stokes
Sent: Wednesday, August 15, 2012 6:43 AM
To: Alia Atlas; Shah, Himanshu
Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
Subject: Re: [irs-discuss] IRS comments

Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?   

Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, August 15, 2012 9:08 AM
To: Shah, Himanshu
Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
Subject: Re: [irs-discuss] IRS comments

Hi Himanshu,

Welcome.   I agree that IRS isn't going to spring into being fully
formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).

Alia

On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>
> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
> We need to make sure that exposed interface to 
> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>
> At the moment it seems like a wild wild west.
> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>
> Thanks,
> himanshu
>
>
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Monday, August 13, 2012 8:41 AM
> To: Scott Whyte
> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
> [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> ...snip...
>
> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>
>>> I do think it is important to have the RIB as an arbitration mechanism
>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>> IRS agent might communicate logically to an IRS routing process 
>>> gives good semantics and interactions.  Obviously, implementations 
>>> may differ.
>>
>> As long as the arbitration mechanism is reconfigurable by the 
>> operator to whatever precedence they want, I agree.  Its not clear to 
>> me if various RIB implementations treat all proffered routes the 
>> same, nor if they store the same meta-data with all protocol sources.  
>> So there needs to be some way for the operator to leverage exposed 
>> protocol-specific optimizations, without conflict from the other 
>> routing processes, if they so desire.  OTOH if it can all be done via 
>> static routes, it seems much simpler. :)
>
> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>
> Alia
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 11:48:20 -0400
From: Alia Atlas <[email-masked]>
To: "David Lake (dlake)" <[email-masked]>
Cc: Olen Stokes <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Hi David,

We do need to clarify what is meant by an application.  I would not
expect that real user-land applications would talk directly to routing
devices via IRS.  I can see that going through an intermediary.  The
IRS abstractions are unlikely to be as high-level as user-land
applications would want and the security and policy issues would get
exciting.

Clarifying what applications are more in-scope initially is part of
where use-cases will help.  Can you write up ones to
categorize/describe your thoughts?

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]> wrote:
> As another newbie to this, I have some questions about "application vendors."
>
> Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."
>
> This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.
>
> However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.
>
> At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.
>
> Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?
>
> Thanks
>
> David
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 7:23 AM
> To: Olen Stokes
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> I have not specifically heard from application vendors about this.
> My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.
>
> More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.
>
> Alia
>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]> wrote:
>> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>>
>> Olen
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Wednesday, August 15, 2012 9:08 AM
>> To: Shah, Himanshu
>> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> Subject: Re: [irs-discuss] IRS comments
>>
>> Hi Himanshu,
>>
>> Welcome.   I agree that IRS isn't going to spring into being fully
>> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>>
>> Alia
>>
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>>
>>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>>> We need to make sure that exposed interface to
>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>>
>>> At the moment it seems like a wild wild west.
>>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>>
>>> Thanks,
>>> himanshu
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> Sent: Monday, August 13, 2012 8:41 AM
>>> To: Scott Whyte
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>> [email-masked]
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>> ...snip...
>>>
>>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>>
>>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>>> IRS agent might communicate logically to an IRS routing process
>>>>> gives good semantics and interactions.  Obviously, implementations
>>>>> may differ.
>>>>
>>>> As long as the arbitration mechanism is reconfigurable by the
>>>> operator to whatever precedence they want, I agree.  Its not clear
>>>> to me if various RIB implementations treat all proffered routes the
>>>> same, nor if they store the same meta-data with all protocol sources.
>>>> So there needs to be some way for the operator to leverage exposed
>>>> protocol-specific optimizations, without conflict from the other
>>>> routing processes, if they so desire.  OTOH if it can all be done
>>>> via static routes, it seems much simpler. :)
>>>
>>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>>
>>> Alia
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "David Lake (dlake)" <[email-masked]>
To: Alia Atlas <[email-masked]>, Olen Stokes <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

As another newbie to this, I have some questions about "application vendors."

Who is the target audience here ?   That will determine what functionality and abstraction of the network we need to expose to that "application."

This presently appears to be a little confused - at least in my mind.  The draft talks very much as if the application we are addressing is an OSS/BSS system, essentially provisioning from the domain owner.

However, linking this to the wider goals of SDN as voiced by customers/users at the first Open Network Summit, there appears to be a desire for cross-domain and user-land application integration.

At this level - as an example giving a content cache the ability to ensure delivery of an HD video to an end user - the application will not be interested in the underlying topology of the network; it will  need to know that application X can be delivered with parameters Y between reading from the content store to delivery to the user's browser.   How the stream traverses the infrastructure is immaterial.

Are we intending that IRS satisfies BOTH these requirements (i.e. for ALL applications ?), or should we be more prescriptive about which application space we are addressing ?

Thanks

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, August 15, 2012 7:23 AM
To: Olen Stokes
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

I have not specifically heard from application vendors about this.
My current plan is that we focus on a Use-Cases draft and define within that some motivating use-cases that we agree are good first targets.  Those can drive which subset of functionality we focus on.

More use-cases are, of course, quite welcome.  Posting them to the mailing list is a good first start.  Russ White is starting the general use-cases draft based on the three use-cases that he sent to the list.

Alia

On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]> wrote:
> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>
> Olen
>
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 9:08 AM
> To: Shah, Himanshu
> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; 
> Alia Atlas; Scott Whyte
> Subject: Re: [irs-discuss] IRS comments
>
> Hi Himanshu,
>
> Welcome.   I agree that IRS isn't going to spring into being fully
> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>
> Alia
>
> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>
>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>> We need to make sure that exposed interface to 
>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>
>> At the moment it seems like a wild wild west.
>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>
>> Thanks,
>> himanshu
>>
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Monday, August 13, 2012 8:41 AM
>> To: Scott Whyte
>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
>> [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> ...snip...
>>
>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>
>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>> IRS agent might communicate logically to an IRS routing process 
>>>> gives good semantics and interactions.  Obviously, implementations 
>>>> may differ.
>>>
>>> As long as the arbitration mechanism is reconfigurable by the 
>>> operator to whatever precedence they want, I agree.  Its not clear 
>>> to me if various RIB implementations treat all proffered routes the 
>>> same, nor if they store the same meta-data with all protocol sources.
>>> So there needs to be some way for the operator to leverage exposed 
>>> protocol-specific optimizations, without conflict from the other 
>>> routing processes, if they so desire.  OTOH if it can all be done 
>>> via static routes, it seems much simpler. :)
>>
>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>
>> Alia
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 15 Aug 2012 10:32:35 -0400
From: Alia Atlas <[email-masked]>
To: [email-masked]
Subject: [irs-discuss] plan before next IETF and drafts

We are trying to ramp IRS up for a BOF at the next IETF.   This means
going very quickly on getting additional focus and drafts together to
explain the focus, scope, use-cases, etc.  Our first goal is to have
an expanded/updated set of drafts by September 10 at the latest.

Among those drafts are at least a General Use-Cases, a
Topology-specific Use-Cases and Requirements, and an IRS protocol
requirements.  We're also looking at a Policy Framework and a draft
about data-model architecture.

If you are interested in contributing to any of these drafts, please
let me know.   If you're working on other related drafts, I'd be
interested in hearing about them.

Also, please send comments on the existing IRS problem-statement and
IRS framework drafts.  I expect that we'll revise them at the end of
the month.

Thanks,
Alia

Date: Wed, 15 Aug 2012 10:23:22 -0400
From: Alia Atlas <[email-masked]>
To: Olen Stokes <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

I have not specifically heard from application vendors about this.
My current plan is that we focus on a Use-Cases draft and define
within that some motivating use-cases that we agree are good first
targets.  Those can drive which subset of functionality we focus on.

More use-cases are, of course, quite welcome.  Posting them to the
mailing list is a good first start.  Russ White is starting the
general use-cases draft based on the three use-cases that he sent to
the list.

Alia

On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes
<[email-masked]> wrote:
> Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?
>
> Olen
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Wednesday, August 15, 2012 9:08 AM
> To: Shah, Himanshu
> Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
> Subject: Re: [irs-discuss] IRS comments
>
> Hi Himanshu,
>
> Welcome.   I agree that IRS isn't going to spring into being fully
> formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).
>
> Alia
>
> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
>> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>>
>> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
>> We need to make sure that exposed interface to
>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>>
>> At the moment it seems like a wild wild west.
>> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>>
>> Thanks,
>> himanshu
>>
>>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Alia Atlas
>> Sent: Monday, August 13, 2012 8:41 AM
>> To: Scott Whyte
>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>> [email-masked]
>> Subject: Re: [irs-discuss] IRS comments
>>
>> ...snip...
>>
>> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>>
>>>> I do think it is important to have the RIB as an arbitration mechanism
>>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>>> IRS agent might communicate logically to an IRS routing process
>>>> gives good semantics and interactions.  Obviously, implementations
>>>> may differ.
>>>
>>> As long as the arbitration mechanism is reconfigurable by the
>>> operator to whatever precedence they want, I agree.  Its not clear to
>>> me if various RIB implementations treat all proffered routes the
>>> same, nor if they store the same meta-data with all protocol sources.
>>> So there needs to be some way for the operator to leverage exposed
>>> protocol-specific optimizations, without conflict from the other
>>> routing processes, if they so desire.  OTOH if it can all be done via
>>> static routes, it seems much simpler. :)
>>
>> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>>
>> Alia
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Olen Stokes <[email-masked]>
To: Alia Atlas <[email-masked]>, "Shah, Himanshu" <[email-masked]>
Date: Wed, 15 Aug 2012 06:43:27 -0700
Accept-Language: en-US
acceptlanguage: en-US
Cc: Gert Grammel <[email-masked]>, "[email-masked]" <[email-masked]>, Lenny Giuliano <[email-masked]>, Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, Scott Whyte <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Are there applications vendors out there that already have specific requirements for what this " subset of the data-models for sub-interfaces"  should be?   

Olen

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Wednesday, August 15, 2012 9:08 AM
To: Shah, Himanshu
Cc: Gert Grammel; [email-masked]; Lenny Giuliano; Thomas Nadeau; Alia Atlas; Scott Whyte
Subject: Re: [irs-discuss] IRS comments

Hi Himanshu,

Welcome.   I agree that IRS isn't going to spring into being fully
formed - I expect that we'll focus on a subset of the data-models for sub-interfaces along with an associated protocol (whether that is a new one or extending an existing one).

Alia

On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>
> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
> We need to make sure that exposed interface to 
> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive action/response/events even when different implementations has varying capabilities.
>
> At the moment it seems like a wild wild west.
> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>
> Thanks,
> himanshu
>
>
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Monday, August 13, 2012 8:41 AM
> To: Scott Whyte
> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; 
> [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> ...snip...
>
> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>
>>> I do think it is important to have the RIB as an arbitration mechanism
>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>> IRS agent might communicate logically to an IRS routing process 
>>> gives good semantics and interactions.  Obviously, implementations 
>>> may differ.
>>
>> As long as the arbitration mechanism is reconfigurable by the 
>> operator to whatever precedence they want, I agree.  Its not clear to 
>> me if various RIB implementations treat all proffered routes the 
>> same, nor if they store the same meta-data with all protocol sources.  
>> So there needs to be some way for the operator to leverage exposed 
>> protocol-specific optimizations, without conflict from the other 
>> routing processes, if they so desire.  OTOH if it can all be done via 
>> static routes, it seems much simpler. :)
>
> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>
> Alia
> _______________________________________________
> 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: Wed, 15 Aug 2012 09:07:39 -0400
From: Alia Atlas <[email-masked]>
To: "Shah, Himanshu" <[email-masked]>
Cc: Gert Grammel <[email-masked]>, "[email-masked]" <[email-masked]>, Lenny Giuliano <[email-masked]>, Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, Scott Whyte <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Hi Himanshu,

Welcome.   I agree that IRS isn't going to spring into being fully
formed - I expect that we'll focus on a subset of the data-models for
sub-interfaces along with an associated protocol (whether that is a
new one or extending an existing one).

Alia

On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]> wrote:
> Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.
>
> I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
> We need to make sure that exposed interface to RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a
> consistent predictive action/response/events even when different implementations has varying capabilities.
>
> At the moment it seems like a wild wild west.
> Perhaps IRS can be defined in phases starting with a simpler, limited version..
>
> Thanks,
> himanshu
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
> Sent: Monday, August 13, 2012 8:41 AM
> To: Scott Whyte
> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; [email-masked]
> Subject: Re: [irs-discuss] IRS comments
>
> ...snip...
>
> On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
>> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
>
>>> I do think it is important to have the RIB as an arbitration mechanism
>>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>>> IRS agent might communicate logically to an IRS routing process gives
>>> good semantics and interactions.  Obviously, implementations may
>>> differ.
>>
>> As long as the arbitration mechanism is reconfigurable by the operator
>> to whatever precedence they want, I agree.  Its not clear to me if
>> various RIB implementations treat all proffered routes the same, nor
>> if they store the same meta-data with all protocol sources.  So there
>> needs to be some way for the operator to leverage exposed
>> protocol-specific optimizations, without conflict from the other
>> routing processes, if they so desire.  OTOH if it can all be done via
>> static routes, it seems much simpler. :)
>
> Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.
>
> Alia
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: "Shah, Himanshu" <[email-masked]>
To: Alia Atlas <[email-masked]>, Scott Whyte <[email-masked]>
Date: Wed, 15 Aug 2012 07:41:26 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Newbie to this discussions list and have read only a last couple of mails, so pardon the repeat if somebody has already raised the following as a concern.

I realize we are early in IRS architecture definition but one thing to keep in mind is the user experience.
We need to make sure that exposed interface to RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a 
consistent predictive action/response/events even when different implementations has varying capabilities.

At the moment it seems like a wild wild west. 
Perhaps IRS can be defined in phases starting with a simpler, limited version..

Thanks,
himanshu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Monday, August 13, 2012 8:41 AM
To: Scott Whyte
Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano; [email-masked]
Subject: Re: [irs-discuss] IRS comments

...snip...

On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:

>> I do think it is important to have the RIB as an arbitration mechanism
>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>> IRS agent might communicate logically to an IRS routing process gives 
>> good semantics and interactions.  Obviously, implementations may 
>> differ.
>
> As long as the arbitration mechanism is reconfigurable by the operator 
> to whatever precedence they want, I agree.  Its not clear to me if 
> various RIB implementations treat all proffered routes the same, nor 
> if they store the same meta-data with all protocol sources.  So there 
> needs to be some way for the operator to leverage exposed 
> protocol-specific optimizations, without conflict from the other 
> routing processes, if they so desire.  OTOH if it can all be done via 
> static routes, it seems much simpler. :)

Clearly the IRS sub-interface for the RIB needs to introduce/define the different precedences; my assumption is that it would be per route with a well-defined small set of meta-data.  This is part of where having good use-cases will help us understand what behavior is necessary.  The static  routes do seem like a simpler case to start with.

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

Date: Mon, 13 Aug 2012 08:41:28 -0400
From: Alia Atlas <[email-masked]>
To: Scott Whyte <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] IRS comments

...snip...

On Fri, Aug 10, 2012 at 9:03 PM, Scott Whyte <[email-masked]> wrote:
> On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:

>> I do think it is important to have the RIB as an arbitration mechanism
>> on the device.   Russ's suggestion that for the RIB sub-interface, the
>> IRS agent might communicate logically to an IRS routing process gives
>> good semantics and interactions.  Obviously, implementations may
>> differ.
>
> As long as the arbitration mechanism is reconfigurable by the operator
> to whatever precedence they want, I agree.  Its not clear to me if
> various RIB implementations treat all proffered routes the same, nor
> if they store the same meta-data with all protocol sources.  So there
> needs to be some way for the operator to leverage exposed
> protocol-specific optimizations, without conflict from the other
> routing processes, if they so desire.  OTOH if it can all be done via
> static routes, it seems much simpler. :)

Clearly the IRS sub-interface for the RIB needs to introduce/define
the different precedences; my assumption is that it would be per route
with a well-defined small set of meta-data.  This is part of where
having good use-cases will help us understand what behavior is
necessary.  The static  routes do seem like a simpler case to start
with.

Alia

zenpKwPquVAiKpxowOInGLSeAMV5K1k9g+axIq730=; b=YKdHJpEUXd/0phllEfrMUHiYXH+MKLwxS6xKds3MaUVz0HTWhoUbzcf/tm1za175yV XrjRdPM7uraNu9UfrU8xeFoO/BkqhRZsZlMyeYf29/MD+h5LWDSATtWVvdl+UeWP+Vlq cY3VBbKErLPvYBYz+tOdRKwZL0Ij+J6DPXQ+cTLNCrvZDA/HyiWf3Um8xufICk/xZylM WiVj65YvjhffvtGPChvSrWZDM8xhdtONiVxgm8GVUL7R+zAf5pisotMOKg5UcVagW0SF WI+2QEUOYfQguemWiTjLB/SLpXT2WwqtXdadEXD7nCXA94aQgtIpcKPwaem04cCNCxX0 hR9g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s 120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record:x-gm-message-state; bh
zenpKwPquVAiKpxowOInGLSeAMV5K1k9g+axIq730=; b=J8VjLtulDBCRQlszHD5jWK/yN3gAiMgiicTMjvdQQsZw7tt0WnXpI1KAi9kBmiSDKS d5RlPo2gSy3pT4IXahtt85X+mBQP83+XEypI8BraH1DUb2sEcL1in4BYr/OH7L/RU0pv U6eY48IMpr8867IWjAidZFegWwiaElqLCUmLXc3e5JyV2I3+CXSP0zOBvDk/JKOCmSQG +ZvGEsApBiSXos+1XQiGZ9B9Ms26/8+VHPeEOFquoXgO8H4acSvhsTQLcuTPzTIWaFDI s5U/jc/sNyKujU4H0JTZI/NSO0DMQ3Z1MTcfOXnN3G4e4MNkp1wXJwNIV/BGaAfaQa+Q nnyA=
Date: Fri, 10 Aug 2012 18:03:11 -0700
From: Scott Whyte <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] IRS comments

On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <[email-masked]> wrote:
> Scott,
>
> In your example, the control plane would mostly move off the device;
> it still exists.  Dave Meyer asked if IRS would work to communicate
> with routing if it were off the device.  I'd be curious to hear
> people's thoughts on that.  My initial take is that IRS's
> sub-interfaces should be useful regardless - but we need a good use
> case describing that and it would, of course, depend on the
> architectural model that moved the routing off the device.

Noel's comment earlier got me thinking it sure would be nice to rip
out all the routing baggage from ISIS, and just use the flooding
mechanism to discover topology.  And as discussed earlier in other
threads, topology discovery does need to be run on the devices
clearly, so I think we are in agreement here.

>
> I do think it is important to have the RIB as an arbitration mechanism
> on the device.   Russ's suggestion that for the RIB sub-interface, the
> IRS agent might communicate logically to an IRS routing process gives
> good semantics and interactions.  Obviously, implementations may
> differ.

As long as the arbitration mechanism is reconfigurable by the operator
to whatever precedence they want, I agree.  Its not clear to me if
various RIB implementations treat all proffered routes the same, nor
if they store the same meta-data with all protocol sources.  So there
needs to be some way for the operator to leverage exposed
protocol-specific optimizations, without conflict from the other
routing processes, if they so desire.  OTOH if it can all be done via
static routes, it seems much simpler. :)

-Scott

>
> Do you have a particular architectural model that you're thinking of
> for having the control plane off the device?  It's something I've
> talked with various folks about - but have yet to see anything
> convincing written down that addresses most of the issues - from link
> verification and MTU to OAM and resiliency and interactions between
> off-device control-plane controllers/orchestrators.
>
>
> Alia
>
> On Fri, Aug 10, 2012 at 7:22 PM, Scott Whyte <[email-masked]> wrote:
>> On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel <[email-masked]> wrote:
>>> Tom,
>>>
>>> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
>>> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
>>> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
>>
>> Alia's presentation has a diagram with a direct link between the IRS
>> Agent and the RIB Manager; thus it does seem to replace routing.
>>
>>> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
>>
>> If none of my switching nodes speak any kind of legacy control plane
>> protocol, yet IRS remains stuffing 500,000 static routes into each
>> (thus programming the network), NPP only makes sense to me if it
>> subsumes the legacy control plane, not co-exists with it as I
>> understand your taxonomy.
>>
>> -Scott
>>
>>>
>>>
>>> Gert
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: [email-masked] <[email-masked]>
>>> To: Lenny Giuliano; Alia Atlas
>>> Cc: [email-masked] <[email-masked]>
>>> Sent: Tue Jul 31 01:50:40 2012
>>> Subject: Re: [irs-discuss] IRS comments
>>>
>>>
>>> [Re-adding IRS]
>>>
>>>         Thank you for reviewing and the comments. We will incorporate the edits
>>> in the next rev.
>>>
>>>         --Tom
>>>
>>>
>>> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>>>
>>>>
>>>>Minor points:
>>>>
>>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>>
>>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>>    remove or read state from the multicast RIB."
>>>>       -How is this unique to mcast?  Couldn't you say the same thing
>>>>       about unicast?
>>>>
>>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>>    installed state.  For instance, traffic received on an specified set,
>>>>    or all, interfaces that is destined to a particular prefix from all
>>>>    sources or a particular prefix could be subject to the specified
>>>>    replication."
>>>>       -Not clear to me at all what this para is saying.
>>>>
>>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>>something as unpopular as taxation (something we learned with AMT).
>>>>Maybe
>>>>RSI instead...
>>>>
>>>>Overall, I found the doc to be clearly written and straightforward.
>>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>>I
>>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>>this
>>>>sounded like our SDK which has been around for years.
>>>>
>>>>
>>>>-Lenny
>>>
>>> _______________________________________________
>>> 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
>>
>>
>>
>> --
>> panem et circenses - a winning strategy for over 2000 years!
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

-- 
panem et circenses - a winning strategy for over 2000 years!

Date: Fri, 10 Aug 2012 20:16:46 -0400
From: Alia Atlas <[email-masked]>
To: Scott Whyte <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] IRS comments

Scott,

In your example, the control plane would mostly move off the device;
it still exists.  Dave Meyer asked if IRS would work to communicate
with routing if it were off the device.  I'd be curious to hear
people's thoughts on that.  My initial take is that IRS's
sub-interfaces should be useful regardless - but we need a good use
case describing that and it would, of course, depend on the
architectural model that moved the routing off the device.

I do think it is important to have the RIB as an arbitration mechanism
on the device.   Russ's suggestion that for the RIB sub-interface, the
IRS agent might communicate logically to an IRS routing process gives
good semantics and interactions.  Obviously, implementations may
differ.

Do you have a particular architectural model that you're thinking of
for having the control plane off the device?  It's something I've
talked with various folks about - but have yet to see anything
convincing written down that addresses most of the issues - from link
verification and MTU to OAM and resiliency and interactions between
off-device control-plane controllers/orchestrators.

Alia

On Fri, Aug 10, 2012 at 7:22 PM, Scott Whyte <[email-masked]> wrote:
> On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel <[email-masked]> wrote:
>> Tom,
>>
>> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
>> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
>> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
>
> Alia's presentation has a diagram with a direct link between the IRS
> Agent and the RIB Manager; thus it does seem to replace routing.
>
>> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
>
> If none of my switching nodes speak any kind of legacy control plane
> protocol, yet IRS remains stuffing 500,000 static routes into each
> (thus programming the network), NPP only makes sense to me if it
> subsumes the legacy control plane, not co-exists with it as I
> understand your taxonomy.
>
> -Scott
>
>>
>>
>> Gert
>>
>>
>>
>>
>> ----- Original Message -----
>> From: [email-masked] <[email-masked]>
>> To: Lenny Giuliano; Alia Atlas
>> Cc: [email-masked] <[email-masked]>
>> Sent: Tue Jul 31 01:50:40 2012
>> Subject: Re: [irs-discuss] IRS comments
>>
>>
>> [Re-adding IRS]
>>
>>         Thank you for reviewing and the comments. We will incorporate the edits
>> in the next rev.
>>
>>         --Tom
>>
>>
>> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>>
>>>
>>>Minor points:
>>>
>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>
>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>    remove or read state from the multicast RIB."
>>>       -How is this unique to mcast?  Couldn't you say the same thing
>>>       about unicast?
>>>
>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>    installed state.  For instance, traffic received on an specified set,
>>>    or all, interfaces that is destined to a particular prefix from all
>>>    sources or a particular prefix could be subject to the specified
>>>    replication."
>>>       -Not clear to me at all what this para is saying.
>>>
>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>something as unpopular as taxation (something we learned with AMT).
>>>Maybe
>>>RSI instead...
>>>
>>>Overall, I found the doc to be clearly written and straightforward.
>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>I
>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>this
>>>sounded like our SDK which has been around for years.
>>>
>>>
>>>-Lenny
>>
>> _______________________________________________
>> 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
>
>
>
> --
> panem et circenses - a winning strategy for over 2000 years!
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Fri, 10 Aug 2012 16:22:53 -0700
From: Scott Whyte <[email-masked]>
To: Gert Grammel <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] IRS comments

On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel <[email-masked]> wrote:
> Tom,
>
> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).

Alia's presentation has a diagram with a direct link between the IRS
Agent and the RIB Manager; thus it does seem to replace routing.

> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.

If none of my switching nodes speak any kind of legacy control plane
protocol, yet IRS remains stuffing 500,000 static routes into each
(thus programming the network), NPP only makes sense to me if it
subsumes the legacy control plane, not co-exists with it as I
understand your taxonomy.

-Scott

>
>
> Gert
>
>
>
>
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
>
>
> [Re-adding IRS]
>
>         Thank you for reviewing and the comments. We will incorporate the edits
> in the next rev.
>
>         --Tom
>
>
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>
>>
>>Minor points:
>>
>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>
>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>    remove or read state from the multicast RIB."
>>       -How is this unique to mcast?  Couldn't you say the same thing
>>       about unicast?
>>
>>-4.1.3 "The multicast state added need not match to well-known protocol
>>    installed state.  For instance, traffic received on an specified set,
>>    or all, interfaces that is destined to a particular prefix from all
>>    sources or a particular prefix could be subject to the specified
>>    replication."
>>       -Not clear to me at all what this para is saying.
>>
>>-"IRS"- you may want to select a different acronym that isn't related to
>>something as unpopular as taxation (something we learned with AMT).
>>Maybe
>>RSI instead...
>>
>>Overall, I found the doc to be clearly written and straightforward.
>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>didn't mention Openflow, but it did seem like an elephant in the room as
>>I
>>was reading thru.  Also, I did wonder what was new and novel here, as
>>this
>>sounded like our SDK which has been around for years.
>>
>>
>>-Lenny
>
> _______________________________________________
> 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

-- 
panem et circenses - a winning strategy for over 2000 years!

Date: Fri, 10 Aug 2012 15:51:51 -0700
From: Scott Whyte <[email-masked]>
To: [email-masked]
Cc: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

On Wed, Aug 8, 2012 at 3:10 AM, Robert Raszuk <[email-masked]> wrote:
> Ed,
>
>
>> If topo information export is in scope (which I believe it is) and
>> PBR route injection with nh recursion to rib (and thus connected
>> routes) is in scope (which I'm quite sure it is) then yes, this is in
>> scope.
>
> Great !
>
>
>> Although I'm not sure what it has to do with OF /OF controllers? ;P
>
>
> One could observe that entire OF can be very easily mapped to well
> implemented and scaable PBR ;)

I guess that depends on what you define Policy Based ROUTING to be ;)

-Scott

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

-- 
panem et circenses - a winning strategy for over 2000 years!

Date: Fri, 10 Aug 2012 16:57:29 -0400
From: Alia Atlas <[email-masked]>
To: [email-masked]
Cc: Susan Hares <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Hi Robert,

The "streaming" adjective will be gone in the next draft revision.  It
was replaced by describing the key attributes needed for the
interface.

At the IGP level, I can see applications adding in new prefixes or
data to distribute.  We have to see what else makes sense for that
sub-interface.

Alia

On Fri, Aug 10, 2012 at 4:43 PM, Robert Raszuk <[email-masked]> wrote:
> Hi Sue,
>
>
>> Robert:
>>
>> I am now confused. Can you give me more examples about the
>> streaming aspect of IRS framework, and why you questioned it.
>>
>> Thanks,
>> Sue Hares
>
>
> The IRS framework draft says streaming 9 times (just few quotes ...):
>
>    This document describes a framework for a standard, programmatic
>    interface for full-duplex, streaming state transfer in and out of the
>    Internet's routing system.
>
> +
>
>    The IRS
>    is a programmatic, streaming interface for transferring state into
>    and out of the Internet's routing system,
>
> ...
>
> 4.3.1.  IGP Interfaces
>
>    The lack of a streaming programmatic interface to the IGPs limits the
>    ability of applications to influence and modify the desired behavior
>    of the IGP.
>
> ...
>
>
>> and why you questioned it.
>
> Since I am quite pessimistic about influencing and modifying behaviour of
> the control plane (example above: IGP) by some external controller driven by
> applications.
>
> IMHO IGP should provide solid domain wide IP paths between the network edges
> and should not be subject to fluctuations on a per application basis.
>
> Best regards,
> R.
>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Fri, 10 Aug 2012 22:43:50 +0200
From: Robert Raszuk <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted
Reply-To: [email-masked]

Hi Sue,

> Robert:
>
> I am now confused. Can you give me more examples about the
> streaming aspect of IRS framework, and why you questioned it.
>
> Thanks,
> Sue Hares

The IRS framework draft says streaming 9 times (just few quotes ...):

    This document describes a framework for a standard, programmatic
    interface for full-duplex, streaming state transfer in and out of the
    Internet's routing system.

+

    The IRS
    is a programmatic, streaming interface for transferring state into
    and out of the Internet's routing system,

...

4.3.1.  IGP Interfaces

    The lack of a streaming programmatic interface to the IGPs limits the
    ability of applications to influence and modify the desired behavior
    of the IGP.

...

 > and why you questioned it.

Since I am quite pessimistic about influencing and modifying behaviour 
of the control plane (example above: IGP) by some external controller 
driven by applications.

IMHO IGP should provide solid domain wide IP paths between the network 
edges and should not be subject to fluctuations on a per application basis.

Best regards,
R.

From: Susan Hares <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 10 Aug 2012 19:42:29 +0000
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>, James Kempf <[email-masked]>, Alia Atlas <[email-masked]>, Thomas Nadeau <[email-masked]>, "Joel M. Halpern" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Robert:

I am now confused. Can you give me more examples about the streaming aspect of IRS framework, and why you questioned it. 

Thanks,

Sue Hares 

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, August 10, 2012 12:40 PM
To: Susan Hares
Cc: Alia Atlas; Thomas Nadeau; James Kempf; Joel M. Halpern; [email-masked]; Thomas Nadeau
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Hi Sue,

My below email expresses no questions or issues towards 
draft-gredler-idr-ls-distribution.

The streaming aspect of IRS framework into BGP or IGPs was questioned.

Best regards,
R.

> Robert:
>
> [Catching up with old email]
>
> Why are you concerned with the streaming aspects of the data from BGP and ISIS?  If you are could you cross post to [email-masked].
> We are considering the draft-gredler-idr-ls-distribution at this time.
>
> Sue
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
> Sent: Monday, July 30, 2012 6:11 PM
> To: Alia Atlas
> Cc: Thomas Nadeau; James Kempf; Joel M. Halpern; [email-masked]; Thomas Nadeau
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> What is not clear for me is ability from arbitrary entities to be able to write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good can be seen as result of this.
>
> Exporting information is fine - no objection at all.
>
> However for programming state into dynamic system the entity which writes in should be the master and not the slave which unfortunately as of now it looks like it is the latter.
>
> Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps just add static routes, perhaps insert network statements into BGP configuration. But till details are defined and till we understand how is this any better from already standards based tools to do the same I think it is well premature to judge any benefit from the IRS framework.
>
> Best Rgs,
> R.
>
>
>
> Sent from my iPad
>
> On Jul 30, 2012, at 5:55 PM, Alia Atlas <[email-masked]> wrote:
>
>> Rob,
>>
>> We've been trying.  I've written semi-copious words so far.
>> I'd be happy to discuss with you in person as well and get your
>> thoughts on reasonable use-cases.
>>
>> Describing an elephant for the first time is always tricky.
>>
>> Perhaps you could describe your perspective on the problem and what
>> you think is unclear.
>>
>> Regards,
>> Alia
>>
>>
>> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk <[email-masked]> wrote:
>>> Tom,
>>>
>>> Yes indeed .. Clearly defining what problem are you trying to solve would be greatly helpful.
>>>
>>> Best,
>>> R.
>>>
>>>
>>> Sent from my iPad
>>>
>>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wrote:
>>>
>>>>
>>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <[email-masked]> wrote:
>>>>
>>>>> Alia, I do have to disagree with one aspect of your characterization fo ForCES.  While the initial design goal was forwarding behavior, the protocol design is such that it is usable over a broad range of abstraction levels.
>>>>>
>>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be suitable / useable.
>>>>
>>>>    We are not ruling out any existing solutions, either in whole or in part (modified). The goal right now is to define the problem space and a framework of components that can be used to solve that problem.
>>>>
>>>>> On the other hand, I think that working out the problems and entities that need to be modeled first (which probably does need a dedicated working group), and then worrying about which protocol meets the requirements when we know what exactly we need.  At that point, the protocol work can be done wherever appropriate.
>>>>
>>>>    Yes, that is precisely what the goals are right now.
>>>>
>>>>    --Tom
>>>>
>>>>
>>>>>
>>>>> yours,
>>>>> Jitl
>>>>>
>>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>>>>> Hi James,
>>>>>>
>>>>>> Thanks for your thoughts.   Streaming (as I've heard) is not as good a
>>>>>> description of the desired interface attributes as described in Sec
>>>>>> 1.1, the functional overview.
>>>>>>
>>>>>> IRS is NOT about having interfaces to the forwarding plane.  That's
>>>>>> what ForCES is focused on.   This is about communication to a router
>>>>>> to install/retrieve routing state into the routing system (FIB, IGPs,
>>>>>> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control plane from the
>>>>>> router.
>>>>>>
>>>>>> Are you suggesting that ForCES should drastically expand its scope?
>>>>>>
>>>>>> Before we start debating what and whether to expand existing
>>>>>> protocols, I think we need a common understanding of the problem we're
>>>>>> trying to solve and the related framework.
>>>>>>
>>>>>> Alia
>>>>>>
>>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> wrote:
>>>>>>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>>>>>>
>>>>>>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>>>>>>
>>>>>>>                jak
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked]
>>>>>>>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>>>>>>>> Sent: Monday, July 30, 2012 11:18 AM
>>>>>>>> To: [email-masked]
>>>>>>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please review and discuss.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tom, Alia, Ward
>>>>>>>>
>>>>>>>>
>>>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> irs-discuss mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> irs-discuss mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>
>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

Date: Fri, 10 Aug 2012 21:40:16 +0200
From: Robert Raszuk <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>, James Kempf <[email-masked]>, Alia Atlas <[email-masked]>, Thomas Nadeau <[email-masked]>, "Joel M. Halpern" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted
Reply-To: [email-masked]

Hi Sue,

My below email expresses no questions or issues towards 
draft-gredler-idr-ls-distribution.

The streaming aspect of IRS framework into BGP or IGPs was questioned.

Best regards,
R.

> Robert:
>
> [Catching up with old email]
>
> Why are you concerned with the streaming aspects of the data from BGP and ISIS?  If you are could you cross post to [email-masked].
> We are considering the draft-gredler-idr-ls-distribution at this time.
>
> Sue
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
> Sent: Monday, July 30, 2012 6:11 PM
> To: Alia Atlas
> Cc: Thomas Nadeau; James Kempf; Joel M. Halpern; [email-masked]; Thomas Nadeau
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> What is not clear for me is ability from arbitrary entities to be able to write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good can be seen as result of this.
>
> Exporting information is fine - no objection at all.
>
> However for programming state into dynamic system the entity which writes in should be the master and not the slave which unfortunately as of now it looks like it is the latter.
>
> Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps just add static routes, perhaps insert network statements into BGP configuration. But till details are defined and till we understand how is this any better from already standards based tools to do the same I think it is well premature to judge any benefit from the IRS framework.
>
> Best Rgs,
> R.
>
>
>
> Sent from my iPad
>
> On Jul 30, 2012, at 5:55 PM, Alia Atlas <[email-masked]> wrote:
>
>> Rob,
>>
>> We've been trying.  I've written semi-copious words so far.
>> I'd be happy to discuss with you in person as well and get your
>> thoughts on reasonable use-cases.
>>
>> Describing an elephant for the first time is always tricky.
>>
>> Perhaps you could describe your perspective on the problem and what
>> you think is unclear.
>>
>> Regards,
>> Alia
>>
>>
>> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk <[email-masked]> wrote:
>>> Tom,
>>>
>>> Yes indeed .. Clearly defining what problem are you trying to solve would be greatly helpful.
>>>
>>> Best,
>>> R.
>>>
>>>
>>> Sent from my iPad
>>>
>>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wrote:
>>>
>>>>
>>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <[email-masked]> wrote:
>>>>
>>>>> Alia, I do have to disagree with one aspect of your characterization fo ForCES.  While the initial design goal was forwarding behavior, the protocol design is such that it is usable over a broad range of abstraction levels.
>>>>>
>>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be suitable / useable.
>>>>
>>>>    We are not ruling out any existing solutions, either in whole or in part (modified). The goal right now is to define the problem space and a framework of components that can be used to solve that problem.
>>>>
>>>>> On the other hand, I think that working out the problems and entities that need to be modeled first (which probably does need a dedicated working group), and then worrying about which protocol meets the requirements when we know what exactly we need.  At that point, the protocol work can be done wherever appropriate.
>>>>
>>>>    Yes, that is precisely what the goals are right now.
>>>>
>>>>    --Tom
>>>>
>>>>
>>>>>
>>>>> yours,
>>>>> Jitl
>>>>>
>>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>>>>> Hi James,
>>>>>>
>>>>>> Thanks for your thoughts.   Streaming (as I've heard) is not as good a
>>>>>> description of the desired interface attributes as described in Sec
>>>>>> 1.1, the functional overview.
>>>>>>
>>>>>> IRS is NOT about having interfaces to the forwarding plane.  That's
>>>>>> what ForCES is focused on.   This is about communication to a router
>>>>>> to install/retrieve routing state into the routing system (FIB, IGPs,
>>>>>> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control plane from the
>>>>>> router.
>>>>>>
>>>>>> Are you suggesting that ForCES should drastically expand its scope?
>>>>>>
>>>>>> Before we start debating what and whether to expand existing
>>>>>> protocols, I think we need a common understanding of the problem we're
>>>>>> trying to solve and the related framework.
>>>>>>
>>>>>> Alia
>>>>>>
>>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> wrote:
>>>>>>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>>>>>>
>>>>>>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>>>>>>
>>>>>>>                jak
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: [email-masked]
>>>>>>>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>>>>>>>> Sent: Monday, July 30, 2012 11:18 AM
>>>>>>>> To: [email-masked]
>>>>>>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Please review and discuss.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Tom, Alia, Ward
>>>>>>>>
>>>>>>>>
>>>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> irs-discuss mailing list
>>>>>>>> [email-masked]
>>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> irs-discuss mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>
>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

From: Susan Hares <[email-masked]>
To: "[email-masked]" <[email-masked]>, Thomas Nadeau <[email-masked]>
Date: Fri, 10 Aug 2012 19:17:32 +0000
Accept-Language: en-US, zh-CN
Cc: James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Robert:

Here's the questions I have to the authors of this draft: 

1. How does this draft prevent sending this non-routing information to the whole BGP peers?

    The draft says private peering.  The question is regarding the private peer - is do the implementations 
    Have the knobs to aid the detection and enforcement of this private peering? 

    I believe you have seen the questions by operators (e.g., Rob).

2. How does this draft impact the ROA work? Is it orthogonal?  Will the ROA work be turned off
   For the draft-gredler-idr-ls-distribution-01? 

3. Is this for IBGP only?  Or is it for EBGP in AS Confederations? 
   How does the RR infrastructure get protected? 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, August 02, 2012 4:30 PM
To: Thomas Nadeau
Cc: James Kempf; [email-masked]
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Tom,

 > I agree that one of the top work items for this effort should be a
 > standardized topology function, and one that is accessible via a
 > non-routing protocol.

So if the requirement is to have topology export via non-routing 
protocol then I think we should seriously revisit or repackage the 
draft-gredler-idr-ls-distribution-01 which works for for both OSPF and 
ISIS.

However before that let's really understand the requirement why it must 
be exported via non-routing protocol .... Keep in mind that just to 
parse BGP UPDATE messages and retrieve interesting pieces out it it 
requires very little code rather then full BGP implementation.

The particular feature I like about draft-gredler-idr-ls-distribution-01 
is that it is read-only ;)

R.

>
> 	I agree that one of the top work items for this effort should be a
> standardized topology function, and one that is accessible via a
> non-routing protocol.  While not exactly "low hanging fruit", it is
> something that (to me) is a clear work item with clear goals that should
> be tackled straight away.
>
> 	--Tom
>
>
>
> On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>
>> So after seeing part of Alia's talk this morning (I had to leave in the
>> middle unfortunately), I'd like to make a couple suggestions. There were
>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>> think to make tangible progress, the work needs to be focussed on a small
>> subset that would be of immediate interest and usability.
>>
>> There are a couple areas that suggest themselves, but one that would be
>> useful in work that I've been involved in is a standardized format for
>> network topology representation and a protocol for exchanging it. The
>> Onix OpenFlow controller has a network information base with a
>> specialized format for network topology, and every OpenFlow controller
>> requires this. Having a standardized way to represent it might foster a
>> common topology database package. Another application is network
>> management. Every network management system needs some kind of topology
>> representation. Finally, though I am not an expert in PCE construction,
>> it would seem to me that a PCE would need some kind of topology
>> representation in order to perform path calculations. Having a way,for
>> example, for the OpenFlow controller and the PCE to exchange topology
>> information would be really useful.  I would say to start with physical
>> topology because that is fundamental, but make the format flexible enough
>> to support
>> virtual topology representation.
>>
>> 			jak
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

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

From: Susan Hares <[email-masked]>
To: Robert Raszuk <[email-masked]>, Alia Atlas <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Robert:

[Catching up with old email]

Why are you concerned with the streaming aspects of the data from BGP and ISIS?  If you are could you cross post to [email-masked]. 
We are considering the draft-gredler-idr-ls-distribution at this time. 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Monday, July 30, 2012 6:11 PM
To: Alia Atlas
Cc: Thomas Nadeau; James Kempf; Joel M. Halpern; [email-masked]; Thomas Nadeau
Subject: Re: [irs-discuss] IRS Problem Statement Posted

What is not clear for me is ability from arbitrary entities to be able to write to BGP or ISIS at sort of ad-hoc streaming. I do not see anything good can be seen as result of this. 

Exporting information is fine - no objection at all.

However for programming state into dynamic system the entity which writes in should be the master and not the slave which unfortunately as of now it looks like it is the latter.

Perhaps you have in mind just adding bunch of ACLs on the edges, perhaps just add static routes, perhaps insert network statements into BGP configuration. But till details are defined and till we understand how is this any better from already standards based tools to do the same I think it is well premature to judge any benefit from the IRS framework.

Best Rgs,
R.

Sent from my iPad

On Jul 30, 2012, at 5:55 PM, Alia Atlas <[email-masked]> wrote:

> Rob,
> 
> We've been trying.  I've written semi-copious words so far.
> I'd be happy to discuss with you in person as well and get your
> thoughts on reasonable use-cases.
> 
> Describing an elephant for the first time is always tricky.
> 
> Perhaps you could describe your perspective on the problem and what
> you think is unclear.
> 
> Regards,
> Alia
> 
> 
> On Mon, Jul 30, 2012 at 7:31 PM, Robert Raszuk <[email-masked]> wrote:
>> Tom,
>> 
>> Yes indeed .. Clearly defining what problem are you trying to solve would be greatly helpful.
>> 
>> Best,
>> R.
>> 
>> 
>> Sent from my iPad
>> 
>> On Jul 30, 2012, at 3:54 PM, Thomas Nadeau <[email-masked]> wrote:
>> 
>>> 
>>> On Jul 30, 2012:3:39 PM, at 3:39 PM, "Joel M. Halpern" <[email-masked]> wrote:
>>> 
>>>> Alia, I do have to disagree with one aspect of your characterization fo ForCES.  While the initial design goal was forwarding behavior, the protocol design is such that it is usable over a broad range of abstraction levels.
>>>> 
>>>> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be suitable / useable.
>>> 
>>>   We are not ruling out any existing solutions, either in whole or in part (modified). The goal right now is to define the problem space and a framework of components that can be used to solve that problem.
>>> 
>>>> On the other hand, I think that working out the problems and entities that need to be modeled first (which probably does need a dedicated working group), and then worrying about which protocol meets the requirements when we know what exactly we need.  At that point, the protocol work can be done wherever appropriate.
>>> 
>>>   Yes, that is precisely what the goals are right now.
>>> 
>>>   --Tom
>>> 
>>> 
>>>> 
>>>> yours,
>>>> Jitl
>>>> 
>>>> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>>>> Hi James,
>>>>> 
>>>>> Thanks for your thoughts.   Streaming (as I've heard) is not as good a
>>>>> description of the desired interface attributes as described in Sec
>>>>> 1.1, the functional overview.
>>>>> 
>>>>> IRS is NOT about having interfaces to the forwarding plane.  That's
>>>>> what ForCES is focused on.   This is about communication to a router
>>>>> to install/retrieve routing state into the routing system (FIB, IGPs,
>>>>> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control plane from the
>>>>> router.
>>>>> 
>>>>> Are you suggesting that ForCES should drastically expand its scope?
>>>>> 
>>>>> Before we start debating what and whether to expand existing
>>>>> protocols, I think we need a common understanding of the problem we're
>>>>> trying to solve and the related framework.
>>>>> 
>>>>> Alia
>>>>> 
>>>>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[email-masked]> wrote:
>>>>>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>>>>> 
>>>>>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>>>>> 
>>>>>>               jak
>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: [email-masked]
>>>>>>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>>>>>>> Sent: Monday, July 30, 2012 11:18 AM
>>>>>>> To: [email-masked]
>>>>>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Please review and discuss.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> Tom, Alia, Ward
>>>>>>> 
>>>>>>> 
>>>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> irs-discuss mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>>> 
>>>>>> _______________________________________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>> 
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> 
>>> 
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Content-Class: urn:content-classes:message
Date: Fri, 10 Aug 2012 04:54:15 +0100
From: Gert Grammel <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] IRS comments

Susan,

Q1: Which NM are you implying here? 
A: traditionally a functional view on the subject has been used. Think about it. Does the fact that a piece of Software monitors a device justify to name it 'Network Management'? Is CLI a Network Management?

Q2: Configuration included download plus transactional (roll forward/roll-back). 
A: that's what's required to keep two persistent databases aligned.

A3: Your description does not match the current status of the IGPs or BGP implementations. 
Q3: what let you to that conclusion?
Those are CP protocols.

Q4: Where do you place the Graceful-Restart or Hitless Restart or High availability work? Do you place this in a PCE or a stateful PCE? 
A4: IETF work is always placed between 2 or more entities because we deal with protocols.

----- Original Message -----
From: Susan Hares <[email-masked]>
To: Gert Grammel; Thomas Nadeau <[email-masked]>
Cc: Thomas Nadeau; Lenny Giuliano; Alia Atlas; [email-masked] <[email-masked]>
Sent: Fri Aug 10 02:51:36 2012
Subject: RE: [irs-discuss] IRS comments

Gert:

I'm interested in discussing the theory of the network management. Tradition Network management (ISO documents) looked at such generic ideas as configuration, performance, fault management, and monitoring. Which NM are you implying here? 

Configuration included download plus transactional (roll forward/roll-back). 

Your description does not match the current status of the IGPs or BGP implementations. 

Where do you place the Graceful-Restart or Hitless Restart or High availability work? Do you place this in a PCE or a stateful PCE? 

Sue 

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]] 
Sent: Thursday, August 09, 2012 1:00 PM
To: Thomas Nadeau; Susan Hares
Cc: Thomas Nadeau; Lenny Giuliano; Alia Atlas; [email-masked]
Subject: RE: [irs-discuss] IRS comments

Susan,

The difference of a NP-plane compared to control and management planes
can best be explained by describing a power cycle:
- The Management plane supervises (Monitoring and Alarms), and when
configuring, it creates persistent state in the switching element as
well as in the Management plane itself. In other words state that
remains in the box (switch and NMS) even after a power cycle. 

- A control plane behaves differently. After a power cycle the switching
element needs to re-learn state from its peers.

- The NPP is a strange hybrid, it can create persistent state in the NPP
but not in the switching element. In other words, if you re-start the
NPP, all configuration comes up as of before. If you re-start the
switching element, it needs to synch up with NPP.

A nice example for a NPP function is e.g. a centralized PCE server. You
can create a lot of persistent rules and parameters there on how to
calculate the path. Those parameters will remain in the PCE-server even
after a PCE-server re-start. Yet the PCE doesn't create persistent
information in the switching elements. If those re-start, they'll have
to re-synch. 

I am well aware that in the past folks positioned various elements (PCE,
RR, IRS, ...) either as part of the Control Plane or a part of the
management plane. And yes, positioning is not an exact science.
Nevertheless I believe that it is now time to give a class name to those
vagabonding objects. 

-- Gert

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, August 09, 2012 9:38 AM
To: Susan Hares
Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas;
[email-masked]
Subject: Re: [irs-discuss] IRS comments

We intended for irs to need both read and write capabilities, hence our
use of "bidirectional" in describing the interface characteristics in
the problem statement.  One big difference between existing "network
management" and what we are trying to specify now is real-time
transactional capabilities.

Tom 

On Aug 9, 2012, at 10:57 AM, Susan Hares <[email-masked]> wrote:

> Gert:
> 
> How do you characterize network management?  Traditionally network
management has been viewed in the IETF in two streams:  monitoring
(active or passive) and configuration.  
> 
> What parts of these features do you think the IRS system needs to
avoid? 
> 
> Sue
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gert Grammel
> Sent: Monday, July 30, 2012 6:41 PM
> To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
> 
> Tom,
> 
> It is confusing to understand whether IRS belongs to a new network
management plane or if it's more of a control plane extension. The draft
wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best
be  characterized as 'Network Programming Plane' NPP. 
> It neither aims to do full provisioning (as a management plane would
do) nor aims to replace routing (as a control plane would do).
> Hence we better name the baby NPP -- thereby avoiding any linkage to
taxation.
> 
> 
> Gert
> 
> 
> 
> 
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
> 
> 
> [Re-adding IRS]
> 
>    Thank you for reviewing and the comments. We will incorporate the 
> edits in the next rev.
> 
>    --Tom
> 
> 
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
> 
>> 
>> Minor points:
>> 
>> -section 4, para 2, 3rd sentence, "Howeve,r"
>> 
>> -4.1.3 "There is no bidirectional programmatic interface to add,
modify,
>>   remove or read state from the multicast RIB."
>>    -How is this unique to mcast?  Couldn't you say the same thing
>>    about unicast?
>> 
>> -4.1.3 "The multicast state added need not match to well-known
protocol
>>   installed state.  For instance, traffic received on an specified
set,
>>   or all, interfaces that is destined to a particular prefix from all
>>   sources or a particular prefix could be subject to the specified
>>   replication."
>>    -Not clear to me at all what this para is saying.
>> 
>> -"IRS"- you may want to select a different acronym that isn't related

>> to something as unpopular as taxation (something we learned with
AMT).
>> Maybe
>> RSI instead...
>> 
>> Overall, I found the doc to be clearly written and straightforward.
>> Sounds like Openflow for routers.  Not sure if it's intentional that 
>> you didn't mention Openflow, but it did seem like an elephant in the 
>> room as I was reading thru.  Also, I did wonder what was new and 
>> novel here, as this sounded like our SDK which has been around for 
>> years.
>> 
>> 
>> -Lenny
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

From: Susan Hares <[email-masked]>
To: Gert Grammel <[email-masked]>, Thomas Nadeau <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Gert:

I'm interested in discussing the theory of the network management. Tradition Network management (ISO documents) looked at such generic ideas as configuration, performance, fault management, and monitoring. Which NM are you implying here? 

Configuration included download plus transactional (roll forward/roll-back). 

Your description does not match the current status of the IGPs or BGP implementations. 

Where do you place the Graceful-Restart or Hitless Restart or High availability work? Do you place this in a PCE or a stateful PCE? 

Sue 

-----Original Message-----
From: Gert Grammel [mailto:[email-masked]] 
Sent: Thursday, August 09, 2012 1:00 PM
To: Thomas Nadeau; Susan Hares
Cc: Thomas Nadeau; Lenny Giuliano; Alia Atlas; [email-masked]
Subject: RE: [irs-discuss] IRS comments

Susan,

The difference of a NP-plane compared to control and management planes
can best be explained by describing a power cycle:
- The Management plane supervises (Monitoring and Alarms), and when
configuring, it creates persistent state in the switching element as
well as in the Management plane itself. In other words state that
remains in the box (switch and NMS) even after a power cycle. 

- A control plane behaves differently. After a power cycle the switching
element needs to re-learn state from its peers.

- The NPP is a strange hybrid, it can create persistent state in the NPP
but not in the switching element. In other words, if you re-start the
NPP, all configuration comes up as of before. If you re-start the
switching element, it needs to synch up with NPP.

A nice example for a NPP function is e.g. a centralized PCE server. You
can create a lot of persistent rules and parameters there on how to
calculate the path. Those parameters will remain in the PCE-server even
after a PCE-server re-start. Yet the PCE doesn't create persistent
information in the switching elements. If those re-start, they'll have
to re-synch. 

I am well aware that in the past folks positioned various elements (PCE,
RR, IRS, ...) either as part of the Control Plane or a part of the
management plane. And yes, positioning is not an exact science.
Nevertheless I believe that it is now time to give a class name to those
vagabonding objects. 

-- Gert

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, August 09, 2012 9:38 AM
To: Susan Hares
Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas;
[email-masked]
Subject: Re: [irs-discuss] IRS comments

We intended for irs to need both read and write capabilities, hence our
use of "bidirectional" in describing the interface characteristics in
the problem statement.  One big difference between existing "network
management" and what we are trying to specify now is real-time
transactional capabilities.

Tom 

On Aug 9, 2012, at 10:57 AM, Susan Hares <[email-masked]> wrote:

> Gert:
> 
> How do you characterize network management?  Traditionally network
management has been viewed in the IETF in two streams:  monitoring
(active or passive) and configuration.  
> 
> What parts of these features do you think the IRS system needs to
avoid? 
> 
> Sue
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gert Grammel
> Sent: Monday, July 30, 2012 6:41 PM
> To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
> 
> Tom,
> 
> It is confusing to understand whether IRS belongs to a new network
management plane or if it's more of a control plane extension. The draft
wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best
be  characterized as 'Network Programming Plane' NPP. 
> It neither aims to do full provisioning (as a management plane would
do) nor aims to replace routing (as a control plane would do).
> Hence we better name the baby NPP -- thereby avoiding any linkage to
taxation.
> 
> 
> Gert
> 
> 
> 
> 
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
> 
> 
> [Re-adding IRS]
> 
>    Thank you for reviewing and the comments. We will incorporate the 
> edits in the next rev.
> 
>    --Tom
> 
> 
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
> 
>> 
>> Minor points:
>> 
>> -section 4, para 2, 3rd sentence, "Howeve,r"
>> 
>> -4.1.3 "There is no bidirectional programmatic interface to add,
modify,
>>   remove or read state from the multicast RIB."
>>    -How is this unique to mcast?  Couldn't you say the same thing
>>    about unicast?
>> 
>> -4.1.3 "The multicast state added need not match to well-known
protocol
>>   installed state.  For instance, traffic received on an specified
set,
>>   or all, interfaces that is destined to a particular prefix from all
>>   sources or a particular prefix could be subject to the specified
>>   replication."
>>    -Not clear to me at all what this para is saying.
>> 
>> -"IRS"- you may want to select a different acronym that isn't related

>> to something as unpopular as taxation (something we learned with
AMT).
>> Maybe
>> RSI instead...
>> 
>> Overall, I found the doc to be clearly written and straightforward.
>> Sounds like Openflow for routers.  Not sure if it's intentional that 
>> you didn't mention Openflow, but it did seem like an elephant in the 
>> room as I was reading thru.  Also, I did wonder what was new and 
>> novel here, as this sounded like our SDK which has been around for 
>> years.
>> 
>> 
>> -Lenny
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

Content-Class: urn:content-classes:message
Date: Thu, 9 Aug 2012 20:59:43 +0100
From: Gert Grammel <[email-masked]>
To: Thomas Nadeau <[email-masked]>, Susan Hares <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] IRS comments

Susan,

The difference of a NP-plane compared to control and management planes
can best be explained by describing a power cycle:
- The Management plane supervises (Monitoring and Alarms), and when
configuring, it creates persistent state in the switching element as
well as in the Management plane itself. In other words state that
remains in the box (switch and NMS) even after a power cycle. 

- A control plane behaves differently. After a power cycle the switching
element needs to re-learn state from its peers.

- The NPP is a strange hybrid, it can create persistent state in the NPP
but not in the switching element. In other words, if you re-start the
NPP, all configuration comes up as of before. If you re-start the
switching element, it needs to synch up with NPP.

A nice example for a NPP function is e.g. a centralized PCE server. You
can create a lot of persistent rules and parameters there on how to
calculate the path. Those parameters will remain in the PCE-server even
after a PCE-server re-start. Yet the PCE doesn't create persistent
information in the switching elements. If those re-start, they'll have
to re-synch. 

I am well aware that in the past folks positioned various elements (PCE,
RR, IRS, ...) either as part of the Control Plane or a part of the
management plane. And yes, positioning is not an exact science.
Nevertheless I believe that it is now time to give a class name to those
vagabonding objects. 

-- Gert

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, August 09, 2012 9:38 AM
To: Susan Hares
Cc: Gert Grammel; Thomas Nadeau; Lenny Giuliano; Alia Atlas;
[email-masked]
Subject: Re: [irs-discuss] IRS comments

We intended for irs to need both read and write capabilities, hence our
use of "bidirectional" in describing the interface characteristics in
the problem statement.  One big difference between existing "network
management" and what we are trying to specify now is real-time
transactional capabilities.

Tom 

On Aug 9, 2012, at 10:57 AM, Susan Hares <[email-masked]> wrote:

> Gert:
> 
> How do you characterize network management?  Traditionally network
management has been viewed in the IETF in two streams:  monitoring
(active or passive) and configuration.  
> 
> What parts of these features do you think the IRS system needs to
avoid? 
> 
> Sue
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gert Grammel
> Sent: Monday, July 30, 2012 6:41 PM
> To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
> 
> Tom,
> 
> It is confusing to understand whether IRS belongs to a new network
management plane or if it's more of a control plane extension. The draft
wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best
be  characterized as 'Network Programming Plane' NPP. 
> It neither aims to do full provisioning (as a management plane would
do) nor aims to replace routing (as a control plane would do).
> Hence we better name the baby NPP -- thereby avoiding any linkage to
taxation.
> 
> 
> Gert
> 
> 
> 
> 
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
> 
> 
> [Re-adding IRS]
> 
>    Thank you for reviewing and the comments. We will incorporate the 
> edits in the next rev.
> 
>    --Tom
> 
> 
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
> 
>> 
>> Minor points:
>> 
>> -section 4, para 2, 3rd sentence, "Howeve,r"
>> 
>> -4.1.3 "There is no bidirectional programmatic interface to add,
modify,
>>   remove or read state from the multicast RIB."
>>    -How is this unique to mcast?  Couldn't you say the same thing
>>    about unicast?
>> 
>> -4.1.3 "The multicast state added need not match to well-known
protocol
>>   installed state.  For instance, traffic received on an specified
set,
>>   or all, interfaces that is destined to a particular prefix from all
>>   sources or a particular prefix could be subject to the specified
>>   replication."
>>    -Not clear to me at all what this para is saying.
>> 
>> -"IRS"- you may want to select a different acronym that isn't related

>> to something as unpopular as taxation (something we learned with
AMT).
>> Maybe
>> RSI instead...
>> 
>> Overall, I found the doc to be clearly written and straightforward.
>> Sounds like Openflow for routers.  Not sure if it's intentional that 
>> you didn't mention Openflow, but it did seem like an elephant in the 
>> room as I was reading thru.  Also, I did wonder what was new and 
>> novel here, as this sounded like our SDK which has been around for 
>> years.
>> 
>> 
>> -Lenny
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

From: Thomas Nadeau <[email-masked]>
Date: Thu, 9 Aug 2012 12:38:12 -0400
To: Susan Hares <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

We intended for irs to need both read and write capabilities, hence our use of "bidirectional" in describing the interface characteristics in the problem statement.  One big difference between existing "network management" and what we are trying to specify now is real-time transactional capabilities.

Tom 

On Aug 9, 2012, at 10:57 AM, Susan Hares <[email-masked]> wrote:

> Gert:
> 
> How do you characterize network management?  Traditionally network management has been viewed in the IETF in two streams:  monitoring (active or passive) and configuration.  
> 
> What parts of these features do you think the IRS system needs to avoid? 
> 
> Sue 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Grammel
> Sent: Monday, July 30, 2012 6:41 PM
> To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
> 
> Tom,
> 
> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP. 
> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
> 
> 
> Gert
> 
> 
> 
> 
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
> 
> 
> [Re-adding IRS]
> 
>    Thank you for reviewing and the comments. We will incorporate the edits
> in the next rev.
> 
>    --Tom
> 
> 
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
> 
>> 
>> Minor points:
>> 
>> -section 4, para 2, 3rd sentence, "Howeve,r"
>> 
>> -4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>   remove or read state from the multicast RIB."
>>    -How is this unique to mcast?  Couldn't you say the same thing
>>    about unicast?
>> 
>> -4.1.3 "The multicast state added need not match to well-known protocol
>>   installed state.  For instance, traffic received on an specified set,
>>   or all, interfaces that is destined to a particular prefix from all
>>   sources or a particular prefix could be subject to the specified
>>   replication."
>>    -Not clear to me at all what this para is saying.
>> 
>> -"IRS"- you may want to select a different acronym that isn't related to
>> something as unpopular as taxation (something we learned with AMT).
>> Maybe 
>> RSI instead...
>> 
>> Overall, I found the doc to be clearly written and straightforward.
>> Sounds like Openflow for routers.  Not sure if it's intentional that you
>> didn't mention Openflow, but it did seem like an elephant in the room as
>> I 
>> was reading thru.  Also, I did wonder what was new and novel here, as
>> this 
>> sounded like our SDK which has been around for years.
>> 
>> 
>> -Lenny
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

Date: Thu, 9 Aug 2012 17:57:45 +0200
From: Hannes Gredler <[email-masked]>
To: Greg Bernstein <[email-masked]>
Cc: [email-masked], Volker Hilt <[email-masked]>, [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] [Idr] [alto]  About ALTO, BGP-LS, IRS

hi greg,

see comments inline prefixed by HG>

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

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

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

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

Date: Thu, 09 Aug 2012 08:47:09 -0700
From: Greg Bernstein <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: [email-masked], Volker Hilt <[email-masked]>, [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, "Y. Richard Yang" <[email-masked]>
Subject: Re: [irs-discuss] [alto]  About ALTO, BGP-LS, IRS

This is a multi-part message in MIME format.
--------------080100050901050805090804
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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

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

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

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

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

Cheers
Greg

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

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

--------------080100050901050805090804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

</pre>
  </body>
</html>

--------------080100050901050805090804--

Date: Thu, 09 Aug 2012 17:03:12 +0200
From: Robert Raszuk <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments
Reply-To: [email-masked]

Hi Sue,

I am not sure about the division you are drawing. Consider SNMP ... it 
has both "get" and "set".

I think for IRS or for any SDN application the below must be combined 
and the boundary you have drawn removed.

Best,
R.

> Gert:
>
> How do you characterize network management?  Traditionally network
> management has been viewed in the IETF in two streams:  monitoring
> (active or passive) and configuration.
>
> What parts of these features do you think the IRS system needs to
> avoid?
>
> Sue
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Gert Grammel Sent:
> Monday, July 30, 2012 6:41 PM To: Thomas Nadeau; Lenny Giuliano; Alia
> Atlas Cc: [email-masked] Subject: Re: [irs-discuss] IRS
> comments
>
> Tom,
>
> It is confusing to understand whether IRS belongs to a new network
> management plane or if it's more of a control plane extension. The
> draft wisely avoids this classification. To me IRS appears to be a
> completely different beast which should best be  characterized as
> 'Network Programming Plane' NPP. It neither aims to do full
> provisioning (as a management plane would do) nor aims to replace
> routing (as a control plane would do). Hence we better name the baby
> NPP -- thereby avoiding any linkage to taxation.
>
>
> Gert
>
>
>
>
> ----- Original Message ----- From: [email-masked]
> <[email-masked]> To: Lenny Giuliano; Alia Atlas Cc:
> [email-masked] <[email-masked]> Sent: Tue Jul 31 01:50:40
> 2012 Subject: Re: [irs-discuss] IRS comments
>
>
> [Re-adding IRS]
>
> Thank you for reviewing and the comments. We will incorporate the
> edits in the next rev.
>
> --Tom
>
>
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>
>>
>> Minor points:
>>
>> -section 4, para 2, 3rd sentence, "Howeve,r"
>>
>> -4.1.3 "There is no bidirectional programmatic interface to add,
>> modify, remove or read state from the multicast RIB." -How is this
>> unique to mcast?  Couldn't you say the same thing about unicast?
>>
>> -4.1.3 "The multicast state added need not match to well-known
>> protocol installed state.  For instance, traffic received on an
>> specified set, or all, interfaces that is destined to a particular
>> prefix from all sources or a particular prefix could be subject to
>> the specified replication." -Not clear to me at all what this para
>> is saying.
>>
>> -"IRS"- you may want to select a different acronym that isn't
>> related to something as unpopular as taxation (something we learned
>> with AMT). Maybe RSI instead...
>>
>> Overall, I found the doc to be clearly written and
>> straightforward. Sounds like Openflow for routers.  Not sure if
>> it's intentional that you didn't mention Openflow, but it did seem
>> like an elephant in the room as I was reading thru.  Also, I did
>> wonder what was new and novel here, as this sounded like our SDK
>> which has been around for years.
>>
>>
>> -Lenny
>
> _______________________________________________ irs-discuss mailing
> list [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________ irs-discuss mailing
> list [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________ irs-discuss mailing
> list [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

From: Susan Hares <[email-masked]>
To: Gert Grammel <[email-masked]>, Thomas Nadeau <[email-masked]>,  Lenny Giuliano <[email-masked]>, Alia Atlas <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Gert:

How do you characterize network management?  Traditionally network management has been viewed in the IETF in two streams:  monitoring (active or passive) and configuration.  

What parts of these features do you think the IRS system needs to avoid? 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Monday, July 30, 2012 6:41 PM
To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

Tom,

It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP. 
It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.

Gert

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Lenny Giuliano; Alia Atlas
Cc: [email-masked] <[email-masked]>
Sent: Tue Jul 31 01:50:40 2012
Subject: Re: [irs-discuss] IRS comments

[Re-adding IRS]

	Thank you for reviewing and the comments. We will incorporate the edits
in the next rev.

	--Tom

On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:

>
>Minor points:
>
>-section 4, para 2, 3rd sentence, "Howeve,r"
>
>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>    remove or read state from the multicast RIB."
> 	-How is this unique to mcast?  Couldn't you say the same thing
> 	about unicast?
>
>-4.1.3 "The multicast state added need not match to well-known protocol
>    installed state.  For instance, traffic received on an specified set,
>    or all, interfaces that is destined to a particular prefix from all
>    sources or a particular prefix could be subject to the specified
>    replication."
> 	-Not clear to me at all what this para is saying.
>
>-"IRS"- you may want to select a different acronym that isn't related to
>something as unpopular as taxation (something we learned with AMT).
>Maybe 
>RSI instead...
>
>Overall, I found the doc to be clearly written and straightforward.
>Sounds like Openflow for routers.  Not sure if it's intentional that you
>didn't mention Openflow, but it did seem like an elephant in the room as
>I 
>was reading thru.  Also, I did wonder what was new and novel here, as
>this 
>sounded like our SDK which has been around for years.
>
>
>-Lenny

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

From: Lin Han <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Thu, 9 Aug 2012 01:51:17 +0000
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

See in line

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 08, 2012 5:43 PM
To: Lin Han
Cc: Thomas Nadeau; Gert Grammel; Lenny Giuliano; Alia Atlas; [email-masked]
Subject: Re: [irs-discuss] IRS comments

Lin,

IRS is about applications being able to provide routing-related state
to a device and learn topology, measurement, relevant events, etc.
from the devices.   It is critical to enable a feedback loop so that
an application can knowledgeably determine what state needs to be
installed.
[Lin] understood. As I said, in simple language, IRS try to provide the programming-ability for router (correct me if I'm wrong). To achieve it, routing programmer (APP) needs to know the topo, state/stats, etc from device, or the event feedback as you said. Definitely, we need a new protocol.

I think it is important to focus on the problem-statement, use-cases,
framework and requirements for IRS.
[Lin] Is there any other issues the problem-statement wants to solve except programming-ability?

People will have their own perspectives on how this can relate to the
work going on in the ONF and other fora.  In the IETF at this stage, I
don't think it is really appropriate to do a serious compare/contrast
draft.    Certainly, if others disagree, I'd be happy to comment on
preliminary write-ups or drafts.
[Lin] I don't object IETF has its own version of SDN or OF. If IETF version will better address issues and solutions, no doubt industry will accept it. From this point of view, comparison with SDN/OF is inevitable no matter if we like or don't like. The important thing is it does not hurt us since comparison can drive us to provide better solution. If we don't compare (intentionally or technically), it will only bring up the confusion and debating.

I believe that IRS offers a useful function for allowing services that
require applications to be able to dynamically program routing state.
That can be on devices that locally implement and use all, some, or
very little of the routing system.  A key component for a device is
the RIB layer that provides indirection and policy to determine which
state to install based upon preference and which applications have
installed it.

The discussion at the Routing Area open meeting did frame and provide
additional context.  I'd recommend listening to that if & when
possible as well as looking at the slides and drafts.

Alia

On Wed, Aug 8, 2012 at 7:56 PM, Lin Han <[email-masked]> wrote:
> Hi, Tom,
>
> I got the slide after digging tons of threads.
> I agree that we should have a tech talk about what is the difference of IRS and SDN/OF. This will make the frame work more convincing.
> For example, after looking at the picture of Alias slide page 5, It cannot stop me to think that IRS protocol does similar things as north bound API, or OF, depending on what is the format of table we are going to use.
> This frame work gave me a impression that we assume that we don't want to simplify router architecture (for example, keep routing protocol running on router; IRS is just an extra new component), then what we can provide the same thing (programming-ability) like SDN. Is this the best solution?
>
> Thanks
> Lin
> -----Original Message-----
> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2012 4:22 PM
> To: Lin Han; Gert Grammel; Lenny Giuliano; Alia Atlas
> Cc: [email-masked]
> Subject: Re: IRS comments
>
>
>
> On 8/8/12 7:14 PM, "Lin Han" <[email-masked]> wrote:
>
>>Similar confusion by wisely avoidance -:)
>>
>>If possible, Someone can draw a simple picture of IRS location in a
>>router with existence of other components.
>
>         Did you see the slides that Alia sent out from the IETF Presentation?
> Unicast me if not and I will get them to you.
>
>>Also, I think people are confused by the comparison with SDN and OF. More
>>clarification will be helpful.
>
>         For that, we really should set up some internal tech talk thing. Slides
> can help, but having a decent presentation on this would go a long way.
> Let me see what we can do in this regard.
>
>         --Tom
>
>
>>
>>Lin
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>On Behalf Of Gert Grammel
>>Sent: Monday, July 30, 2012 6:41 PM
>>To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
>>Cc: [email-masked]
>>Subject: Re: [irs-discuss] IRS comments
>>
>>Tom,
>>
>>It is confusing to understand whether IRS belongs to a new network
>>management plane or if it's more of a control plane extension. The draft
>>wisely avoids this classification.
>>To me IRS appears to be a completely different beast which should best be
>> characterized as 'Network Programming Plane' NPP.
>>It neither aims to do full provisioning (as a management plane would do)
>>nor aims to replace routing (as a control plane would do).
>>Hence we better name the baby NPP -- thereby avoiding any linkage to
>>taxation.
>>
>>
>>Gert
>>
>>
>>
>>
>>----- Original Message -----
>>From: [email-masked] <[email-masked]>
>>To: Lenny Giuliano; Alia Atlas
>>Cc: [email-masked] <[email-masked]>
>>Sent: Tue Jul 31 01:50:40 2012
>>Subject: Re: [irs-discuss] IRS comments
>>
>>
>>[Re-adding IRS]
>>
>>       Thank you for reviewing and the comments. We will incorporate the edits
>>in the next rev.
>>
>>       --Tom
>>
>>
>>On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>>
>>>
>>>Minor points:
>>>
>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>
>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>    remove or read state from the multicast RIB."
>>>      -How is this unique to mcast?  Couldn't you say the same thing
>>>      about unicast?
>>>
>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>    installed state.  For instance, traffic received on an specified set,
>>>    or all, interfaces that is destined to a particular prefix from all
>>>    sources or a particular prefix could be subject to the specified
>>>    replication."
>>>      -Not clear to me at all what this para is saying.
>>>
>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>something as unpopular as taxation (something we learned with AMT).
>>>Maybe
>>>RSI instead...
>>>
>>>Overall, I found the doc to be clearly written and straightforward.
>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>I
>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>this
>>>sounded like our SDK which has been around for years.
>>>
>>>
>>>-Lenny
>>
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 8 Aug 2012 20:42:43 -0400
From: Alia Atlas <[email-masked]>
To: Lin Han <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Lin,

IRS is about applications being able to provide routing-related state
to a device and learn topology, measurement, relevant events, etc.
from the devices.   It is critical to enable a feedback loop so that
an application can knowledgeably determine what state needs to be
installed.

I think it is important to focus on the problem-statement, use-cases,
framework and requirements for IRS.

People will have their own perspectives on how this can relate to the
work going on in the ONF and other fora.  In the IETF at this stage, I
don't think it is really appropriate to do a serious compare/contrast
draft.    Certainly, if others disagree, I'd be happy to comment on
preliminary write-ups or drafts.

I believe that IRS offers a useful function for allowing services that
require applications to be able to dynamically program routing state.
That can be on devices that locally implement and use all, some, or
very little of the routing system.  A key component for a device is
the RIB layer that provides indirection and policy to determine which
state to install based upon preference and which applications have
installed it.

The discussion at the Routing Area open meeting did frame and provide
additional context.  I'd recommend listening to that if & when
possible as well as looking at the slides and drafts.

Alia

On Wed, Aug 8, 2012 at 7:56 PM, Lin Han <[email-masked]> wrote:
> Hi, Tom,
>
> I got the slide after digging tons of threads.
> I agree that we should have a tech talk about what is the difference of IRS and SDN/OF. This will make the frame work more convincing.
> For example, after looking at the picture of Alias slide page 5, It cannot stop me to think that IRS protocol does similar things as north bound API, or OF, depending on what is the format of table we are going to use.
> This frame work gave me a impression that we assume that we don't want to simplify router architecture (for example, keep routing protocol running on router; IRS is just an extra new component), then what we can provide the same thing (programming-ability) like SDN. Is this the best solution?
>
> Thanks
> Lin
> -----Original Message-----
> From: Thomas Nadeau [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2012 4:22 PM
> To: Lin Han; Gert Grammel; Lenny Giuliano; Alia Atlas
> Cc: [email-masked]
> Subject: Re: IRS comments
>
>
>
> On 8/8/12 7:14 PM, "Lin Han" <[email-masked]> wrote:
>
>>Similar confusion by wisely avoidance -:)
>>
>>If possible, Someone can draw a simple picture of IRS location in a
>>router with existence of other components.
>
>         Did you see the slides that Alia sent out from the IETF Presentation?
> Unicast me if not and I will get them to you.
>
>>Also, I think people are confused by the comparison with SDN and OF. More
>>clarification will be helpful.
>
>         For that, we really should set up some internal tech talk thing. Slides
> can help, but having a decent presentation on this would go a long way.
> Let me see what we can do in this regard.
>
>         --Tom
>
>
>>
>>Lin
>>
>>-----Original Message-----
>>From: [email-masked] [mailto:[email-masked]]
>>On Behalf Of Gert Grammel
>>Sent: Monday, July 30, 2012 6:41 PM
>>To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
>>Cc: [email-masked]
>>Subject: Re: [irs-discuss] IRS comments
>>
>>Tom,
>>
>>It is confusing to understand whether IRS belongs to a new network
>>management plane or if it's more of a control plane extension. The draft
>>wisely avoids this classification.
>>To me IRS appears to be a completely different beast which should best be
>> characterized as 'Network Programming Plane' NPP.
>>It neither aims to do full provisioning (as a management plane would do)
>>nor aims to replace routing (as a control plane would do).
>>Hence we better name the baby NPP -- thereby avoiding any linkage to
>>taxation.
>>
>>
>>Gert
>>
>>
>>
>>
>>----- Original Message -----
>>From: [email-masked] <[email-masked]>
>>To: Lenny Giuliano; Alia Atlas
>>Cc: [email-masked] <[email-masked]>
>>Sent: Tue Jul 31 01:50:40 2012
>>Subject: Re: [irs-discuss] IRS comments
>>
>>
>>[Re-adding IRS]
>>
>>       Thank you for reviewing and the comments. We will incorporate the edits
>>in the next rev.
>>
>>       --Tom
>>
>>
>>On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>>
>>>
>>>Minor points:
>>>
>>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>>
>>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>>    remove or read state from the multicast RIB."
>>>      -How is this unique to mcast?  Couldn't you say the same thing
>>>      about unicast?
>>>
>>>-4.1.3 "The multicast state added need not match to well-known protocol
>>>    installed state.  For instance, traffic received on an specified set,
>>>    or all, interfaces that is destined to a particular prefix from all
>>>    sources or a particular prefix could be subject to the specified
>>>    replication."
>>>      -Not clear to me at all what this para is saying.
>>>
>>>-"IRS"- you may want to select a different acronym that isn't related to
>>>something as unpopular as taxation (something we learned with AMT).
>>>Maybe
>>>RSI instead...
>>>
>>>Overall, I found the doc to be clearly written and straightforward.
>>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>>didn't mention Openflow, but it did seem like an elephant in the room as
>>>I
>>>was reading thru.  Also, I did wonder what was new and novel here, as
>>>this
>>>sounded like our SDK which has been around for years.
>>>
>>>
>>>-Lenny
>>
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Lin Han <[email-masked]>
To: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>,  Lenny Giuliano <[email-masked]>, Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 23:56:10 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Hi, Tom,

I got the slide after digging tons of threads.
I agree that we should have a tech talk about what is the difference of IRS and SDN/OF. This will make the frame work more convincing.
For example, after looking at the picture of Alias slide page 5, It cannot stop me to think that IRS protocol does similar things as north bound API, or OF, depending on what is the format of table we are going to use.
This frame work gave me a impression that we assume that we don't want to simplify router architecture (for example, keep routing protocol running on router; IRS is just an extra new component), then what we can provide the same thing (programming-ability) like SDN. Is this the best solution?

Thanks
Lin
-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Wednesday, August 08, 2012 4:22 PM
To: Lin Han; Gert Grammel; Lenny Giuliano; Alia Atlas
Cc: [email-masked]
Subject: Re: IRS comments

On 8/8/12 7:14 PM, "Lin Han" <[email-masked]> wrote:

>Similar confusion by wisely avoidance -:)
>
>If possible, Someone can draw a simple picture of IRS location in a
>router with existence of other components.

	Did you see the slides that Alia sent out from the IETF Presentation?
Unicast me if not and I will get them to you.

>Also, I think people are confused by the comparison with SDN and OF. More
>clarification will be helpful.

	For that, we really should set up some internal tech talk thing. Slides
can help, but having a decent presentation on this would go a long way.
Let me see what we can do in this regard.

	--Tom

>
>Lin 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Gert Grammel
>Sent: Monday, July 30, 2012 6:41 PM
>To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
>Cc: [email-masked]
>Subject: Re: [irs-discuss] IRS comments
>
>Tom,
>
>It is confusing to understand whether IRS belongs to a new network
>management plane or if it's more of a control plane extension. The draft
>wisely avoids this classification.
>To me IRS appears to be a completely different beast which should best be
> characterized as 'Network Programming Plane' NPP.
>It neither aims to do full provisioning (as a management plane would do)
>nor aims to replace routing (as a control plane would do).
>Hence we better name the baby NPP -- thereby avoiding any linkage to
>taxation.
>
>
>Gert
>
>
>
>
>----- Original Message -----
>From: [email-masked] <[email-masked]>
>To: Lenny Giuliano; Alia Atlas
>Cc: [email-masked] <[email-masked]>
>Sent: Tue Jul 31 01:50:40 2012
>Subject: Re: [irs-discuss] IRS comments
>
>
>[Re-adding IRS]
>
>	Thank you for reviewing and the comments. We will incorporate the edits
>in the next rev.
>
>	--Tom
>
>
>On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>
>>
>>Minor points:
>>
>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>
>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>    remove or read state from the multicast RIB."
>> 	-How is this unique to mcast?  Couldn't you say the same thing
>> 	about unicast?
>>
>>-4.1.3 "The multicast state added need not match to well-known protocol
>>    installed state.  For instance, traffic received on an specified set,
>>    or all, interfaces that is destined to a particular prefix from all
>>    sources or a particular prefix could be subject to the specified
>>    replication."
>> 	-Not clear to me at all what this para is saying.
>>
>>-"IRS"- you may want to select a different acronym that isn't related to
>>something as unpopular as taxation (something we learned with AMT).
>>Maybe 
>>RSI instead...
>>
>>Overall, I found the doc to be clearly written and straightforward.
>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>didn't mention Openflow, but it did seem like an elephant in the room as
>>I 
>>was reading thru.  Also, I did wonder what was new and novel here, as
>>this 
>>sounded like our SDK which has been around for years.
>>
>>
>>-Lenny
>
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Thomas Nadeau <[email-masked]>
Date: Wed, 8 Aug 2012 19:53:18 -0400
To: Lin Han <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Gert Grammel <[email-masked]>, Alia Atlas <[email-masked]>, Lenny Giuliano <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

The slides can be found here:

http://www.lucidvision.com/draft-ward-irs-framework-00.pptx 

On Aug 8, 2012:7:14 PM, at 7:14 PM, Lin Han <[email-masked]> wrote:

> Similar confusion by wisely avoidance -:)
> 
> If possible, Someone can draw a simple picture of IRS location in a router with existence of other components.
> 
> Also, I think people are confused by the comparison with SDN and OF. More clarification will be helpful.
> 
> Lin 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Grammel
> Sent: Monday, July 30, 2012 6:41 PM
> To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
> Cc: [email-masked]
> Subject: Re: [irs-discuss] IRS comments
> 
> Tom,
> 
> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP. 
> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
> 
> 
> Gert
> 
> 
> 
> 
> ----- Original Message -----
> From: [email-masked] <[email-masked]>
> To: Lenny Giuliano; Alia Atlas
> Cc: [email-masked] <[email-masked]>
> Sent: Tue Jul 31 01:50:40 2012
> Subject: Re: [irs-discuss] IRS comments
> 
> 
> [Re-adding IRS]
> 
> 	Thank you for reviewing and the comments. We will incorporate the edits
> in the next rev.
> 
> 	--Tom
> 
> 
> On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
> 
>> 
>> Minor points:
>> 
>> -section 4, para 2, 3rd sentence, "Howeve,r"
>> 
>> -4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>   remove or read state from the multicast RIB."
>> 	-How is this unique to mcast?  Couldn't you say the same thing
>> 	about unicast?
>> 
>> -4.1.3 "The multicast state added need not match to well-known protocol
>>   installed state.  For instance, traffic received on an specified set,
>>   or all, interfaces that is destined to a particular prefix from all
>>   sources or a particular prefix could be subject to the specified
>>   replication."
>> 	-Not clear to me at all what this para is saying.
>> 
>> -"IRS"- you may want to select a different acronym that isn't related to
>> something as unpopular as taxation (something we learned with AMT).
>> Maybe 
>> RSI instead...
>> 
>> Overall, I found the doc to be clearly written and straightforward.
>> Sounds like Openflow for routers.  Not sure if it's intentional that you
>> didn't mention Openflow, but it did seem like an elephant in the room as
>> I 
>> was reading thru.  Also, I did wonder what was new and novel here, as
>> this 
>> sounded like our SDK which has been around for years.
>> 
>> 
>> -Lenny
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

From: Thomas Nadeau <[email-masked]>
To: Lin Han <[email-masked]>, Gert Grammel <[email-masked]>, Lenny Giuliano <[email-masked]>, Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 19:21:58 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

On 8/8/12 7:14 PM, "Lin Han" <[email-masked]> wrote:

>Similar confusion by wisely avoidance -:)
>
>If possible, Someone can draw a simple picture of IRS location in a
>router with existence of other components.

	Did you see the slides that Alia sent out from the IETF Presentation?
Unicast me if not and I will get them to you.

>Also, I think people are confused by the comparison with SDN and OF. More
>clarification will be helpful.

	For that, we really should set up some internal tech talk thing. Slides
can help, but having a decent presentation on this would go a long way.
Let me see what we can do in this regard.

	--Tom

>
>Lin 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Gert Grammel
>Sent: Monday, July 30, 2012 6:41 PM
>To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
>Cc: [email-masked]
>Subject: Re: [irs-discuss] IRS comments
>
>Tom,
>
>It is confusing to understand whether IRS belongs to a new network
>management plane or if it's more of a control plane extension. The draft
>wisely avoids this classification.
>To me IRS appears to be a completely different beast which should best be
> characterized as 'Network Programming Plane' NPP.
>It neither aims to do full provisioning (as a management plane would do)
>nor aims to replace routing (as a control plane would do).
>Hence we better name the baby NPP -- thereby avoiding any linkage to
>taxation.
>
>
>Gert
>
>
>
>
>----- Original Message -----
>From: [email-masked] <[email-masked]>
>To: Lenny Giuliano; Alia Atlas
>Cc: [email-masked] <[email-masked]>
>Sent: Tue Jul 31 01:50:40 2012
>Subject: Re: [irs-discuss] IRS comments
>
>
>[Re-adding IRS]
>
>	Thank you for reviewing and the comments. We will incorporate the edits
>in the next rev.
>
>	--Tom
>
>
>On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:
>
>>
>>Minor points:
>>
>>-section 4, para 2, 3rd sentence, "Howeve,r"
>>
>>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>>    remove or read state from the multicast RIB."
>> 	-How is this unique to mcast?  Couldn't you say the same thing
>> 	about unicast?
>>
>>-4.1.3 "The multicast state added need not match to well-known protocol
>>    installed state.  For instance, traffic received on an specified set,
>>    or all, interfaces that is destined to a particular prefix from all
>>    sources or a particular prefix could be subject to the specified
>>    replication."
>> 	-Not clear to me at all what this para is saying.
>>
>>-"IRS"- you may want to select a different acronym that isn't related to
>>something as unpopular as taxation (something we learned with AMT).
>>Maybe 
>>RSI instead...
>>
>>Overall, I found the doc to be clearly written and straightforward.
>>Sounds like Openflow for routers.  Not sure if it's intentional that you
>>didn't mention Openflow, but it did seem like an elephant in the room as
>>I 
>>was reading thru.  Also, I did wonder what was new and novel here, as
>>this 
>>sounded like our SDK which has been around for years.
>>
>>
>>-Lenny
>
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Lin Han <[email-masked]>
To: Gert Grammel <[email-masked]>, Thomas Nadeau <[email-masked]>,  Lenny Giuliano <[email-masked]>, Alia Atlas <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS comments

Similar confusion by wisely avoidance -:)

If possible, Someone can draw a simple picture of IRS location in a router with existence of other components.

Also, I think people are confused by the comparison with SDN and OF. More clarification will be helpful.

Lin 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Grammel
Sent: Monday, July 30, 2012 6:41 PM
To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
Cc: [email-masked]
Subject: Re: [irs-discuss] IRS comments

Tom,

It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP. 
It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.

Gert

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Lenny Giuliano; Alia Atlas
Cc: [email-masked] <[email-masked]>
Sent: Tue Jul 31 01:50:40 2012
Subject: Re: [irs-discuss] IRS comments

[Re-adding IRS]

	Thank you for reviewing and the comments. We will incorporate the edits
in the next rev.

	--Tom

On 7/30/12 5:04 PM, "Lenny Giuliano" <[email-masked]> wrote:

>
>Minor points:
>
>-section 4, para 2, 3rd sentence, "Howeve,r"
>
>-4.1.3 "There is no bidirectional programmatic interface to add, modify,
>    remove or read state from the multicast RIB."
> 	-How is this unique to mcast?  Couldn't you say the same thing
> 	about unicast?
>
>-4.1.3 "The multicast state added need not match to well-known protocol
>    installed state.  For instance, traffic received on an specified set,
>    or all, interfaces that is destined to a particular prefix from all
>    sources or a particular prefix could be subject to the specified
>    replication."
> 	-Not clear to me at all what this para is saying.
>
>-"IRS"- you may want to select a different acronym that isn't related to
>something as unpopular as taxation (something we learned with AMT).
>Maybe 
>RSI instead...
>
>Overall, I found the doc to be clearly written and straightforward.
>Sounds like Openflow for routers.  Not sure if it's intentional that you
>didn't mention Openflow, but it did seem like an elephant in the room as
>I 
>was reading thru.  Also, I did wonder what was new and novel here, as
>this 
>sounded like our SDK which has been around for years.
>
>
>-Lenny

_______________________________________________
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: Wed, 8 Aug 2012 07:59:07 -0700
From: David Meyer <[email-masked]>
To: Tina TSOU <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

On Tue, Aug 7, 2012 at 9:07 PM, Tina TSOU <[email-masked]> wrote:
> So, r u updating Nitin's statement as following?
>
> Top layer: Northboundapi

#dmm: I propose we depricate the term "Northbound API".  It is pretty
much (if not completely)  meaningless.
>
> Middle layer: IRS
>
> Bottom layer: IRS (topo export)

>
>
> Tina
>
> On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <[email-masked]> wrote:
>
> The requirement for topology export is DEFINITELY part of IRS.  It is
> a crucial piece for a meaningful feedback loop.   Clearly there are
> existing technology pieces that may have a role to play as well.
>
> Alia
>
> On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU <[email-masked]>
> wrote:
>
> Oh, I meant in Nitin's description in the mailing list, there are 3
> sub-layers of a orchestrator.
>
> Top layer: Northboundapi
>
> Middle layer: IRS
>
> Bottom layer: topo export
>
>
> Therefore, the topo export is not part of IRS. It is another layer which
> sits below IRS.
>
>
> Tina
>
>
> On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]> wrote:
>
>
> Topology export is definitely under the umbrella of IRS - and we are
>
> actively starting to think about the associated requirements and
>
> use-cases.   Feel free to contribute - on the list or towards drafts!
>
>
> Alia
>
>
> On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]>
> wrote:
>
> Nitin said topo information export is on the sub-layer under IRS.
>
>
>
>
> Tina
>
>
>
>
> From: [email-masked] [mailto:[email-masked]] On
>
> Behalf Of Edward Crabbe
>
> Sent: Tuesday, August 07, 2012 3:20 PM
>
> To: [email-masked]
>
> Cc: [email-masked]
>
>
>
> Subject: Re: [irs-discuss] An idea ... MTR + IRS
>
>
>
>
> Robert,
>
>
>
>
> If topo information export is in scope (which I believe it is) and PBR route
>
> injection with nh recursion to rib (and thus connected routes) is in scope
>
> (which I'm quite sure it is) then yes, this is in scope.
>
>
>
>
> Although I'm not sure what it has to do with OF /OF controllers? ;P
>
>
> On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]> wrote:
>
>
> Hi,
>
>
> This morning Scott mentioned that he would like to use IRS to shut down all
>
> protocols and just be able to write to RIB. Now James said that he would
>
> like to get a network topology as "every OpenFlow controller requires this"
>
>
> Both connected together resulted in an idea of using multi-topology-routing
>
> where your base topology discovers physical link connectivity graph while
>
> other topologies could be programmed by external entities example: OF
>
> controllers or any other external to routers network intelligence oracles to
>
> deliver actual services ?
>
>
> Would that be in scope of IRS effort ? If so what would be the proposed
>
> "write to RIB" set of protocols ? Would you support OF 1.3 even if one would
>
> be happy to lock such topologies only to software/programmable switching
>
> paths ?
>
>
> Best rgs,
>
> R.
>
> _______________________________________________
>
> irs-discuss mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
>
> _______________________________________________
>
> irs-discuss mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

Date: Wed, 08 Aug 2012 12:10:45 +0200
From: Robert Raszuk <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS
Reply-To: [email-masked]

Ed,

 > If topo information export is in scope (which I believe it is) and
 > PBR route injection with nh recursion to rib (and thus connected
 > routes) is in scope (which I'm quite sure it is) then yes, this is in
 > scope.

Great !

> Although I'm not sure what it has to do with OF /OF controllers? ;P

One could observe that entire OF can be very easily mapped to well 
implemented and scaable PBR ;)

Best,
R.

Date: Wed, 8 Aug 2012 01:33:02 -0400
From: Alia Atlas <[email-masked]>
To: Tina TSOU <[email-masked]>
Cc: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Tina,

IRS makes no statement about orchestrators; I'm pretty sure the word
doesn't appear in either draft at all.  Certainly an orchestrator is a
type of application that could use IRS.

IRS includes routing state, topology, and the ability to get
measurements and dynamic events.  All may be needed for a meaningful
feedback loop run by an application.

Alia

On Wed, Aug 8, 2012 at 1:24 AM, Tina TSOU <[email-masked]> wrote:
> Alia,
> It is just to clarification.
> Just to confirm that draft-atlas and draft-ward state that IRS positions below the northboudapi in an orchestrator, and IRS includes both routing state and topo export. Is it correct understanding?
> Thank you.
>
> Tina
>
>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Tuesday, August 07, 2012 9:38 PM
>> To: Tina TSOU
>> Cc: Edward Crabbe; [email-masked]; [email-masked]
>> Subject: Re: [irs-discuss] An idea ... MTR + IRS
>>
>> Tina,
>>
>> Nitin made a single comment on this list that you are reading too much
>> into.
>>
>> I have written the two base drafts for IRS and am working on driving
>> the definition of the work that is proposed.  The presentation that I
>> gave in Routing Area Open Meeting CLEARLY describes topology as not
>> only being in the proposed scope, but one of the more urgent items.
>>
>> Why are you NOT listening?
>>
>> Perhaps rereading the problem-statement and framework drafts would
>> help clarify your mental model?
>>
>> IRS does not talk about a northboundapi - there are applications that
>> can use IRS.  How those applications communicate with other
>> applications is NOT in the proposed scope.
>>
>> Alia
>>
>> On Wed, Aug 8, 2012 at 12:07 AM, Tina TSOU
>> <[email-masked]> wrote:
>> > So, r u updating Nitin's statement as following?
>> >
>> > Top layer: Northboundapi
>> >
>> > Middle layer: IRS
>> >
>> > Bottom layer: IRS (topo export)
>> >
>> >
>> > Tina
>> >
>> > On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <[email-masked]> wrote:
>> >
>> > The requirement for topology export is DEFINITELY part of IRS.  It is
>> > a crucial piece for a meaningful feedback loop.   Clearly there are
>> > existing technology pieces that may have a role to play as well.
>> >
>> > Alia
>> >
>> > On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU
>> <[email-masked]>
>> > wrote:
>> >
>> > Oh, I meant in Nitin's description in the mailing list, there are 3
>> > sub-layers of a orchestrator.
>> >
>> > Top layer: Northboundapi
>> >
>> > Middle layer: IRS
>> >
>> > Bottom layer: topo export
>> >
>> >
>> > Therefore, the topo export is not part of IRS. It is another layer
>> which
>> > sits below IRS.
>> >
>> >
>> > Tina
>> >
>> >
>> > On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]> wrote:
>> >
>> >
>> > Topology export is definitely under the umbrella of IRS - and we are
>> >
>> > actively starting to think about the associated requirements and
>> >
>> > use-cases.   Feel free to contribute - on the list or towards drafts!
>> >
>> >
>> > Alia
>> >
>> >
>> > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU
>> <[email-masked]>
>> > wrote:
>> >
>> > Nitin said topo information export is on the sub-layer under IRS.
>> >
>> >
>> >
>> >
>> > Tina
>> >
>> >
>> >
>> >
>> > From: [email-masked] [mailto:irs-discuss-
>> [email-masked]] On
>> >
>> > Behalf Of Edward Crabbe
>> >
>> > Sent: Tuesday, August 07, 2012 3:20 PM
>> >
>> > To: [email-masked]
>> >
>> > Cc: [email-masked]
>> >
>> >
>> >
>> > Subject: Re: [irs-discuss] An idea ... MTR + IRS
>> >
>> >
>> >
>> >
>> > Robert,
>> >
>> >
>> >
>> >
>> > If topo information export is in scope (which I believe it is) and
>> PBR route
>> >
>> > injection with nh recursion to rib (and thus connected routes) is in
>> scope
>> >
>> > (which I'm quite sure it is) then yes, this is in scope.
>> >
>> >
>> >
>> >
>> > Although I'm not sure what it has to do with OF /OF controllers? ;P
>> >
>> >
>> > On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]>
>> wrote:
>> >
>> >
>> > Hi,
>> >
>> >
>> > This morning Scott mentioned that he would like to use IRS to shut
>> down all
>> >
>> > protocols and just be able to write to RIB. Now James said that he
>> would
>> >
>> > like to get a network topology as "every OpenFlow controller requires
>> this"
>> >
>> >
>> > Both connected together resulted in an idea of using multi-topology-
>> routing
>> >
>> > where your base topology discovers physical link connectivity graph
>> while
>> >
>> > other topologies could be programmed by external entities example: OF
>> >
>> > controllers or any other external to routers network intelligence
>> oracles to
>> >
>> > deliver actual services ?
>> >
>> >
>> > Would that be in scope of IRS effort ? If so what would be the
>> proposed
>> >
>> > "write to RIB" set of protocols ? Would you support OF 1.3 even if
>> one would
>> >
>> > be happy to lock such topologies only to software/programmable
>> switching
>> >
>> > paths ?
>> >
>> >
>> > Best rgs,
>> >
>> > R.
>> >
>> > _______________________________________________
>> >
>> > irs-discuss mailing list
>> >
>> > [email-masked]
>> >
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> >
>> > irs-discuss mailing list
>> >
>> > [email-masked]
>> >
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> >
>> >

From: Tina TSOU <[email-masked]>
To: Alia Atlas <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Alia,
It is just to clarification.
Just to confirm that draft-atlas and draft-ward state that IRS positions below the northboudapi in an orchestrator, and IRS includes both routing state and topo export. Is it correct understanding?
Thank you.

Tina

> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Tuesday, August 07, 2012 9:38 PM
> To: Tina TSOU
> Cc: Edward Crabbe; [email-masked]; [email-masked]
> Subject: Re: [irs-discuss] An idea ... MTR + IRS
> 
> Tina,
> 
> Nitin made a single comment on this list that you are reading too much
> into.
> 
> I have written the two base drafts for IRS and am working on driving
> the definition of the work that is proposed.  The presentation that I
> gave in Routing Area Open Meeting CLEARLY describes topology as not
> only being in the proposed scope, but one of the more urgent items.
> 
> Why are you NOT listening?
> 
> Perhaps rereading the problem-statement and framework drafts would
> help clarify your mental model?
> 
> IRS does not talk about a northboundapi - there are applications that
> can use IRS.  How those applications communicate with other
> applications is NOT in the proposed scope.
> 
> Alia
> 
> On Wed, Aug 8, 2012 at 12:07 AM, Tina TSOU
> <[email-masked]> wrote:
> > So, r u updating Nitin's statement as following?
> >
> > Top layer: Northboundapi
> >
> > Middle layer: IRS
> >
> > Bottom layer: IRS (topo export)
> >
> >
> > Tina
> >
> > On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <[email-masked]> wrote:
> >
> > The requirement for topology export is DEFINITELY part of IRS.  It is
> > a crucial piece for a meaningful feedback loop.   Clearly there are
> > existing technology pieces that may have a role to play as well.
> >
> > Alia
> >
> > On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU
> <[email-masked]>
> > wrote:
> >
> > Oh, I meant in Nitin's description in the mailing list, there are 3
> > sub-layers of a orchestrator.
> >
> > Top layer: Northboundapi
> >
> > Middle layer: IRS
> >
> > Bottom layer: topo export
> >
> >
> > Therefore, the topo export is not part of IRS. It is another layer
> which
> > sits below IRS.
> >
> >
> > Tina
> >
> >
> > On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]> wrote:
> >
> >
> > Topology export is definitely under the umbrella of IRS - and we are
> >
> > actively starting to think about the associated requirements and
> >
> > use-cases.   Feel free to contribute - on the list or towards drafts!
> >
> >
> > Alia
> >
> >
> > On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU
> <[email-masked]>
> > wrote:
> >
> > Nitin said topo information export is on the sub-layer under IRS.
> >
> >
> >
> >
> > Tina
> >
> >
> >
> >
> > From: [email-masked] [mailto:irs-discuss-
> [email-masked]] On
> >
> > Behalf Of Edward Crabbe
> >
> > Sent: Tuesday, August 07, 2012 3:20 PM
> >
> > To: [email-masked]
> >
> > Cc: [email-masked]
> >
> >
> >
> > Subject: Re: [irs-discuss] An idea ... MTR + IRS
> >
> >
> >
> >
> > Robert,
> >
> >
> >
> >
> > If topo information export is in scope (which I believe it is) and
> PBR route
> >
> > injection with nh recursion to rib (and thus connected routes) is in
> scope
> >
> > (which I'm quite sure it is) then yes, this is in scope.
> >
> >
> >
> >
> > Although I'm not sure what it has to do with OF /OF controllers? ;P
> >
> >
> > On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]>
> wrote:
> >
> >
> > Hi,
> >
> >
> > This morning Scott mentioned that he would like to use IRS to shut
> down all
> >
> > protocols and just be able to write to RIB. Now James said that he
> would
> >
> > like to get a network topology as "every OpenFlow controller requires
> this"
> >
> >
> > Both connected together resulted in an idea of using multi-topology-
> routing
> >
> > where your base topology discovers physical link connectivity graph
> while
> >
> > other topologies could be programmed by external entities example: OF
> >
> > controllers or any other external to routers network intelligence
> oracles to
> >
> > deliver actual services ?
> >
> >
> > Would that be in scope of IRS effort ? If so what would be the
> proposed
> >
> > "write to RIB" set of protocols ? Would you support OF 1.3 even if
> one would
> >
> > be happy to lock such topologies only to software/programmable
> switching
> >
> > paths ?
> >
> >
> > Best rgs,
> >
> > R.
> >
> > _______________________________________________
> >
> > 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: Wed, 8 Aug 2012 00:38:15 -0400
From: Alia Atlas <[email-masked]>
To: Tina TSOU <[email-masked]>
Cc: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Tina,

Nitin made a single comment on this list that you are reading too much into.

I have written the two base drafts for IRS and am working on driving
the definition of the work that is proposed.  The presentation that I
gave in Routing Area Open Meeting CLEARLY describes topology as not
only being in the proposed scope, but one of the more urgent items.

Why are you NOT listening?

Perhaps rereading the problem-statement and framework drafts would
help clarify your mental model?

IRS does not talk about a northboundapi - there are applications that
can use IRS.  How those applications communicate with other
applications is NOT in the proposed scope.

Alia

On Wed, Aug 8, 2012 at 12:07 AM, Tina TSOU <[email-masked]> wrote:
> So, r u updating Nitin's statement as following?
>
> Top layer: Northboundapi
>
> Middle layer: IRS
>
> Bottom layer: IRS (topo export)
>
>
> Tina
>
> On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <[email-masked]> wrote:
>
> The requirement for topology export is DEFINITELY part of IRS.  It is
> a crucial piece for a meaningful feedback loop.   Clearly there are
> existing technology pieces that may have a role to play as well.
>
> Alia
>
> On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU <[email-masked]>
> wrote:
>
> Oh, I meant in Nitin's description in the mailing list, there are 3
> sub-layers of a orchestrator.
>
> Top layer: Northboundapi
>
> Middle layer: IRS
>
> Bottom layer: topo export
>
>
> Therefore, the topo export is not part of IRS. It is another layer which
> sits below IRS.
>
>
> Tina
>
>
> On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]> wrote:
>
>
> Topology export is definitely under the umbrella of IRS - and we are
>
> actively starting to think about the associated requirements and
>
> use-cases.   Feel free to contribute - on the list or towards drafts!
>
>
> Alia
>
>
> On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]>
> wrote:
>
> Nitin said topo information export is on the sub-layer under IRS.
>
>
>
>
> Tina
>
>
>
>
> From: [email-masked] [mailto:[email-masked]] On
>
> Behalf Of Edward Crabbe
>
> Sent: Tuesday, August 07, 2012 3:20 PM
>
> To: [email-masked]
>
> Cc: [email-masked]
>
>
>
> Subject: Re: [irs-discuss] An idea ... MTR + IRS
>
>
>
>
> Robert,
>
>
>
>
> If topo information export is in scope (which I believe it is) and PBR route
>
> injection with nh recursion to rib (and thus connected routes) is in scope
>
> (which I'm quite sure it is) then yes, this is in scope.
>
>
>
>
> Although I'm not sure what it has to do with OF /OF controllers? ;P
>
>
> On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]> wrote:
>
>
> Hi,
>
>
> This morning Scott mentioned that he would like to use IRS to shut down all
>
> protocols and just be able to write to RIB. Now James said that he would
>
> like to get a network topology as "every OpenFlow controller requires this"
>
>
> Both connected together resulted in an idea of using multi-topology-routing
>
> where your base topology discovers physical link connectivity graph while
>
> other topologies could be programmed by external entities example: OF
>
> controllers or any other external to routers network intelligence oracles to
>
> deliver actual services ?
>
>
> Would that be in scope of IRS effort ? If so what would be the proposed
>
> "write to RIB" set of protocols ? Would you support OF 1.3 even if one would
>
> be happy to lock such topologies only to software/programmable switching
>
> paths ?
>
>
> Best rgs,
>
> R.
>
> _______________________________________________
>
> irs-discuss mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
>
> _______________________________________________
>
> irs-discuss mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

From: Tina TSOU <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 04:07:51 +0000
Accept-Language: en-US, zh-CN
Cc: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

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

So, r u updating Nitin's statement as following?
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: IRS (topo export)

Tina

On Aug 7, 2012, at 9:01 PM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

The requirement for topology export is DEFINITELY part of IRS.  It is
a crucial piece for a meaningful feedback loop.   Clearly there are
existing technology pieces that may have a role to play as well.

Alia

On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Oh, I meant in Nitin's description in the mailing list, there are 3 sub-layers of a orchestrator.
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: topo export

Therefore, the topo export is not part of IRS. It is another layer which sits below IRS.

Tina

On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]<mailto:[email-masked]>> wrote:

Topology export is definitely under the umbrella of IRS - and we are
actively starting to think about the associated requirements and
use-cases.   Feel free to contribute - on the list or towards drafts!

Alia

On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]<mailto:[email-masked]>> wrote:
Nitin said topo information export is on the sub-layer under IRS.

Tina

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On
Behalf Of Edward Crabbe
Sent: Tuesday, August 07, 2012 3:20 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>

Subject: Re: [irs-discuss] An idea ... MTR + IRS

Robert,

If topo information export is in scope (which I believe it is) and PBR route
injection with nh recursion to rib (and thus connected routes) is in scope
(which I'm quite sure it is) then yes, this is in scope.

Although I'm not sure what it has to do with OF /OF controllers? ;P

On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

This morning Scott mentioned that he would like to use IRS to shut down all
protocols and just be able to write to RIB. Now James said that he would
like to get a network topology as "every OpenFlow controller requires this"

Both connected together resulted in an idea of using multi-topology-routing
where your base topology discovers physical link connectivity graph while
other topologies could be programmed by external entities example: OF
controllers or any other external to routers network intelligence oracles to
deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed
"write to RIB" set of protocols ? Would you support OF 1.3 even if one would
be happy to lock such topologies only to software/programmable switching
paths ?

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

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

--_000_472BCA45046245E0BE89339799915A9Chuaweicom_
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 bgcolor="#FFFFFF">
<div><span class="Apple-style-span" style="-webkit-tap-highlight-color: rgba(26, 26, 26, 0.296875); -webkit-composition-fill-color: rgba(175, 192, 227, 0.230469); -webkit-composition-frame-color: rgba(77, 128, 180, 0.230469); ">
<div>So, r u updating Nitin's statement as following?</div>
<div>
<blockquote type="cite"><font class="Apple-style-span" color="#000000">Top layer: Northboundapi<br>
</font></blockquote>
<blockquote type="cite"><font class="Apple-style-span" color="#000000"><span>Middle layer: IRS</span><br>
</font></blockquote>
<blockquote type="cite"><font class="Apple-style-span" color="#000000">Bottom layer: IRS (topo export)</font></blockquote>
</div>
</span><br>
Tina</div>
<div><br>
On Aug 7, 2012, at 9:01 PM, &quot;Alia Atlas&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br>
<br>
</div>
<div></div>
<blockquote type="cite">
<div><span>The requirement for topology export is DEFINITELY part of IRS. &nbsp;It is</span><br>
<span>a crucial piece for a meaningful feedback loop. &nbsp;&nbsp;Clearly there are</span><br>
<span>existing technology pieces that may have a role to play as well.</span><br>
<span></span><br>
<span>Alia</span><br>
<span></span><br>
<span>On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><br>
<blockquote type="cite"><span>Oh, I meant in Nitin's description in the mailing list, there are 3 sub-layers of a orchestrator.</span><br>
</blockquote>
<blockquote type="cite"><span>Top layer: Northboundapi</span><br>
</blockquote>
<blockquote type="cite"><span>Middle layer: IRS</span><br>
</blockquote>
<blockquote type="cite"><span>Bottom layer: topo export</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Therefore, the topo export is not part of IRS. It is another layer which sits below IRS.</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>Tina</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite"><span>On Aug 7, 2012, at 5:30 PM, &quot;Alia Atlas&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><br>
</blockquote>
<blockquote type="cite"><span></span><br>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>Topology export is definitely under the umbrella of IRS - and we are</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>actively starting to think about the associated requirements and</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>use-cases. &nbsp;&nbsp;Feel free to contribute - on the list or towards drafts!</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>Alia</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite"><span>On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><br>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Nitin said topo information export is on the sub-layer under IRS.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Tina</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>From: <a href="mailto:[email-masked]">
[email-masked]</a> [mailto:[email-masked]] On</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Behalf Of Edward Crabbe</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Sent: Tuesday, August 07, 2012 3:20 PM</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>To: <a href="mailto:[email-masked]">[email-masked]</a></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Cc: <a href="mailto:[email-masked]">[email-masked]</a></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Subject: Re: [irs-discuss] An idea ... MTR &#43; IRS</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Robert,</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>If topo information export is in scope (which I believe it is) and PBR route</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>injection with nh recursion to rib (and thus connected routes) is in scope</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>(which I'm quite sure it is) then yes, this is in scope.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Although I'm not sure what it has to do with OF /OF controllers? ;P</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Hi,</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>This morning Scott mentioned that he would like to use IRS to shut down all</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>protocols and just be able to write to RIB. Now James said that he would</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>like to get a network topology as &quot;every OpenFlow controller requires this&quot;</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Both connected together resulted in an idea of using multi-topology-routing</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>where your base topology discovers physical link connectivity graph while</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>other topologies could be programmed by external entities example: OF</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>controllers or any other external to routers network intelligence oracles to</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>deliver actual services ?</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Would that be in scope of IRS effort ? If so what would be the proposed</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>&quot;write to RIB&quot; set of protocols ? Would you support OF 1.3 even if one would</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>be happy to lock such topologies only to software/programmable switching</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>paths ?</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>Best rgs,</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>R.</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>_______________________________________________</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>irs-discuss mailing list</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span><a href="mailto:[email-masked]">[email-masked]</a></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span><a href="https://www.ietf.org/mailman/listinfo/irs-discuss">https://www.ietf.org/mailman/listinfo/irs-discuss</a></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>_______________________________________________</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span>irs-discuss mailing list</span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span><a href="mailto:[email-masked]">[email-masked]</a></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span><a href="https://www.ietf.org/mailman/listinfo/irs-discuss">https://www.ietf.org/mailman/listinfo/irs-discuss</a></span><br>
</blockquote>
</blockquote>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite"><span></span><br>
</blockquote>
</blockquote>
</blockquote>
</div>
</blockquote>
</body>
</html>

--_000_472BCA45046245E0BE89339799915A9Chuaweicom_--

Date: Wed, 8 Aug 2012 00:01:49 -0400
From: Alia Atlas <[email-masked]>
To: Tina TSOU <[email-masked]>
Cc: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

The requirement for topology export is DEFINITELY part of IRS.  It is
a crucial piece for a meaningful feedback loop.   Clearly there are
existing technology pieces that may have a role to play as well.

Alia

On Tue, Aug 7, 2012 at 10:40 PM, Tina TSOU <[email-masked]> wrote:
> Oh, I meant in Nitin's description in the mailing list, there are 3 sub-layers of a orchestrator.
> Top layer: Northboundapi
> Middle layer: IRS
> Bottom layer: topo export
>
> Therefore, the topo export is not part of IRS. It is another layer which sits below IRS.
>
> Tina
>
> On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]> wrote:
>
>> Topology export is definitely under the umbrella of IRS - and we are
>> actively starting to think about the associated requirements and
>> use-cases.   Feel free to contribute - on the list or towards drafts!
>>
>> Alia
>>
>> On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]> wrote:
>>> Nitin said topo information export is on the sub-layer under IRS.
>>>
>>>
>>>
>>> Tina
>>>
>>>
>>>
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Edward Crabbe
>>> Sent: Tuesday, August 07, 2012 3:20 PM
>>> To: [email-masked]
>>> Cc: [email-masked]
>>>
>>>
>>> Subject: Re: [irs-discuss] An idea ... MTR + IRS
>>>
>>>
>>>
>>> Robert,
>>>
>>>
>>>
>>> If topo information export is in scope (which I believe it is) and PBR route
>>> injection with nh recursion to rib (and thus connected routes) is in scope
>>> (which I'm quite sure it is) then yes, this is in scope.
>>>
>>>
>>>
>>> Although I'm not sure what it has to do with OF /OF controllers? ;P
>>>
>>> On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]> wrote:
>>>
>>> Hi,
>>>
>>> This morning Scott mentioned that he would like to use IRS to shut down all
>>> protocols and just be able to write to RIB. Now James said that he would
>>> like to get a network topology as "every OpenFlow controller requires this"
>>>
>>> Both connected together resulted in an idea of using multi-topology-routing
>>> where your base topology discovers physical link connectivity graph while
>>> other topologies could be programmed by external entities example: OF
>>> controllers or any other external to routers network intelligence oracles to
>>> deliver actual services ?
>>>
>>> Would that be in scope of IRS effort ? If so what would be the proposed
>>> "write to RIB" set of protocols ? Would you support OF 1.3 even if one would
>>> be happy to lock such topologies only to software/programmable switching
>>> paths ?
>>>
>>> Best rgs,
>>> R.
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>

From: Tina TSOU <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 02:40:46 +0000
Accept-Language: en-US, zh-CN
Cc: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Oh, I meant in Nitin's description in the mailing list, there are 3 sub-layers of a orchestrator.
Top layer: Northboundapi
Middle layer: IRS
Bottom layer: topo export

Therefore, the topo export is not part of IRS. It is another layer which sits below IRS.

Tina

On Aug 7, 2012, at 5:30 PM, "Alia Atlas" <[email-masked]> wrote:

> Topology export is definitely under the umbrella of IRS - and we are
> actively starting to think about the associated requirements and
> use-cases.   Feel free to contribute - on the list or towards drafts!
> 
> Alia
> 
> On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]> wrote:
>> Nitin said topo information export is on the sub-layer under IRS.
>> 
>> 
>> 
>> Tina
>> 
>> 
>> 
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Edward Crabbe
>> Sent: Tuesday, August 07, 2012 3:20 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> 
>> 
>> Subject: Re: [irs-discuss] An idea ... MTR + IRS
>> 
>> 
>> 
>> Robert,
>> 
>> 
>> 
>> If topo information export is in scope (which I believe it is) and PBR route
>> injection with nh recursion to rib (and thus connected routes) is in scope
>> (which I'm quite sure it is) then yes, this is in scope.
>> 
>> 
>> 
>> Although I'm not sure what it has to do with OF /OF controllers? ;P
>> 
>> On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]> wrote:
>> 
>> Hi,
>> 
>> This morning Scott mentioned that he would like to use IRS to shut down all
>> protocols and just be able to write to RIB. Now James said that he would
>> like to get a network topology as "every OpenFlow controller requires this"
>> 
>> Both connected together resulted in an idea of using multi-topology-routing
>> where your base topology discovers physical link connectivity graph while
>> other topologies could be programmed by external entities example: OF
>> controllers or any other external to routers network intelligence oracles to
>> deliver actual services ?
>> 
>> Would that be in scope of IRS effort ? If so what would be the proposed
>> "write to RIB" set of protocols ? Would you support OF 1.3 even if one would
>> be happy to lock such topologies only to software/programmable switching
>> paths ?
>> 
>> Best rgs,
>> R.
>> _______________________________________________
>> 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: Tue, 7 Aug 2012 20:30:26 -0400
From: Alia Atlas <[email-masked]>
To: Tina TSOU <[email-masked]>, Edward Crabbe <[email-masked]>,  "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Topology export is definitely under the umbrella of IRS - and we are
actively starting to think about the associated requirements and
use-cases.   Feel free to contribute - on the list or towards drafts!

Alia

On Tue, Aug 7, 2012 at 6:23 PM, Tina TSOU <[email-masked]> wrote:
> Nitin said topo information export is on the sub-layer under IRS.
>
>
>
> Tina
>
>
>
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Edward Crabbe
> Sent: Tuesday, August 07, 2012 3:20 PM
> To: [email-masked]
> Cc: [email-masked]
>
>
> Subject: Re: [irs-discuss] An idea ... MTR + IRS
>
>
>
> Robert,
>
>
>
> If topo information export is in scope (which I believe it is) and PBR route
> injection with nh recursion to rib (and thus connected routes) is in scope
> (which I'm quite sure it is) then yes, this is in scope.
>
>
>
> Although I'm not sure what it has to do with OF /OF controllers? ;P
>
> On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]> wrote:
>
> Hi,
>
> This morning Scott mentioned that he would like to use IRS to shut down all
> protocols and just be able to write to RIB. Now James said that he would
> like to get a network topology as "every OpenFlow controller requires this"
>
> Both connected together resulted in an idea of using multi-topology-routing
> where your base topology discovers physical link connectivity graph while
> other topologies could be programmed by external entities example: OF
> controllers or any other external to routers network intelligence oracles to
> deliver actual services ?
>
> Would that be in scope of IRS effort ? If so what would be the proposed
> "write to RIB" set of protocols ? Would you support OF 1.3 even if one would
> be happy to lock such topologies only to software/programmable switching
> paths ?
>
> Best rgs,
> R.
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

From: Tina TSOU <[email-masked]>
To: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

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

Nitin said topo information export is on the sub-layer under IRS.

Tina

From: [email-masked] [mailto:[email-masked]] On Behalf Of Edward Crabbe
Sent: Tuesday, August 07, 2012 3:20 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Robert,

If topo information export is in scope (which I believe it is) and PBR route injection with nh recursion to rib (and thus connected routes) is in scope (which I'm quite sure it is) then yes, this is in scope.

Although I'm not sure what it has to do with OF /OF controllers? ;P
On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

This morning Scott mentioned that he would like to use IRS to shut down all protocols and just be able to write to RIB. Now James said that he would like to get a network topology as "every OpenFlow controller requires this"

Both connected together resulted in an idea of using multi-topology-routing where your base topology discovers physical link connectivity graph while other topologies could be programmed by external entities example: OF controllers or any other external to routers network intelligence oracles to deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed "write to RIB" set of protocols ? Would you support OF 1.3 even if one would be happy to lock such topologies only to software/programmable switching paths ?

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

--_000_C0E0A32284495243BDE0AC8A066631A81589DBDCdfweml513mbschi_
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:x="urn:schemas-microsoft-com:office:excel" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:z="#RowsetSchema" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rtc="http://microsoft.com/officenet/conferencing" xmlns:D="DAV:" xmlns:Repl="http://schemas.microsoft.com/repl/" xmlns:mt="http://schemas.microsoft.com/sharepoint/soap/meetings/" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:ppda="http://www.passport.com/NameSpace.xsd" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:Z="urn:schemas-microsoft-com:" xmlns:st="&#1;" 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:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@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;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
/* 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;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.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"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Nitin said topo information export is on the sub-layer under IRS.<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">Tina<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>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<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;"> [email-masked] [mailto:[email-masked]]
<b>On Behalf Of </b>Edward Crabbe<br>
<b>Sent:</b> Tuesday, August 07, 2012 3:20 PM<br>
<b>To:</b> [email-masked]<br>
<b>Cc:</b> [email-masked]<br>
<b>Subject:</b> Re: [irs-discuss] An idea ... MTR &#43; IRS<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal">Robert,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<p class="MsoNormal">If topo information export is in scope (which I believe it is) and PBR route injection with nh recursion to rib (and thus connected routes) is in scope (which I'm quite sure it is) then yes, this is in scope.&nbsp;<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">Although I'm not sure what it has to do with OF /OF controllers? ;P<o:p></o:p></p>
<div>
<p class="MsoNormal">On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk &lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt; wrote:<o:p></o:p></p>
<p class="MsoNormal">Hi,<br>
<br>
This morning Scott mentioned that he would like to use IRS to shut down all protocols and just be able to write to RIB. Now James said that he would like to get a network topology as &quot;every OpenFlow controller requires this&quot;<br>
<br>
Both connected together resulted in an idea of using multi-topology-routing where your base topology discovers physical link connectivity graph while other topologies could be programmed by external entities example: OF controllers or any other external to
 routers network intelligence oracles to deliver actual services ?<br>
<br>
Would that be in scope of IRS effort ? If so what would be the proposed &quot;write to RIB&quot; set of protocols ? Would you support OF 1.3 even if one would be happy to lock such topologies only to software/programmable switching paths ?<br>
<br>
Best rgs,<br>
R.<br>
_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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><o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</div>
</div>
</body>
</html>

--_000_C0E0A32284495243BDE0AC8A066631A81589DBDCdfweml513mbschi_--

From: Thomas Nadeau <[email-masked]>
To: Edward Crabbe <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 7 Aug 2012 18:22:28 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

I agree. The only related thing is that you can run both on the same box, effectively creating another "hybrid" scenario, or as we like to call it, tri-brid. *)

--Tom

From: Edward Crabbe <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, August 7, 2012 6:19 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

Robert,

If topo information export is in scope (which I believe it is) and PBR route injection with nh recursion to rib (and thus connected routes) is in scope (which I'm quite sure it is) then yes, this is in scope.

Although I'm not sure what it has to do with OF /OF controllers? ;P

On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

This morning Scott mentioned that he would like to use IRS to shut down all protocols and just be able to write to RIB. Now James said that he would like to get a network topology as "every OpenFlow controller requires this"

Both connected together resulted in an idea of using multi-topology-routing where your base topology discovers physical link connectivity graph while other topologies could be programmed by external entities example: OF controllers or any other external to routers network intelligence oracles to deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed "write to RIB" set of protocols ? Would you support OF 1.3 even if one would be happy to lock such topologies only to software/programmable switching paths ?

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

From: Edward Crabbe <[email-masked]>
Date: Tue, 7 Aug 2012 15:19:40 -0700
To: [email-masked]
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] An idea ... MTR + IRS

--90e6ba6e8c5a67089404c6b46661
Content-Type: text/plain; charset=ISO-8859-1

Robert,

If topo information export is in scope (which I believe it is) and PBR
route injection with nh recursion to rib (and thus connected routes) is in
scope (which I'm quite sure it is) then yes, this is in scope.

Although I'm not sure what it has to do with OF /OF controllers? ;P

On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <[email-masked]> wrote:

> Hi,
>
> This morning Scott mentioned that he would like to use IRS to shut down
> all protocols and just be able to write to RIB. Now James said that he
> would like to get a network topology as "every OpenFlow controller requires
> this"
>
> Both connected together resulted in an idea of using
> multi-topology-routing where your base topology discovers physical link
> connectivity graph while other topologies could be programmed by external
> entities example: OF controllers or any other external to routers network
> intelligence oracles to deliver actual services ?
>
> Would that be in scope of IRS effort ? If so what would be the proposed
> "write to RIB" set of protocols ? Would you support OF 1.3 even if one
> would be happy to lock such topologies only to software/programmable
> switching paths ?
>
> Best rgs,
> R.
> ______________________________**_________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>

--90e6ba6e8c5a67089404c6b46661
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div>Robert,</div><div><br></div>If topo information export is in scope (which I believe it is) and PBR route injection with nh recursion to rib (and thus connected routes) is in scope (which I&#39;m quite sure it is) then yes, this is in scope. <div>

<br></div><div>Although I&#39;m not sure what it has to do with OF /OF controllers? ;P<br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 5:02 PM, Robert Raszuk <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">Hi,<br>
<br>
This morning Scott mentioned that he would like to use IRS to shut down all protocols and just be able to write to RIB. Now James said that he would like to get a network topology as &quot;every OpenFlow controller requires this&quot;<br>

<br>
Both connected together resulted in an idea of using multi-topology-routing where your base topology discovers physical link connectivity graph while other topologies could be programmed by external entities example: OF controllers or any other external to routers network intelligence oracles to deliver actual services ?<br>

<br>
Would that be in scope of IRS effort ? If so what would be the proposed &quot;write to RIB&quot; set of protocols ? Would you support OF 1.3 even if one would be happy to lock such topologies only to software/programmable switching paths ?<br>

<br>
Best rgs,<br>
R.<br>
______________________________<u></u>_________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/<u></u>listinfo/irs-discuss</a><br>
</blockquote></div><br></div>

--90e6ba6e8c5a67089404c6b46661--

From: Lin Han <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 7 Aug 2012 20:58:06 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [irs-discuss] An idea ... MTR + IRS

I think the MT will provide the network virtualization which is based on the basic topo of the forwarding device.
It should belong to either orchestration or application (SDN point of view). OF controller should only support OF, no more intelligence such as decision for routing and switching.
I don't know if IRS frame work should cover this since IRS frame work has a lot debatable areas.

Lin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, August 02, 2012 5:02 PM
To: [email-masked]
Subject: [irs-discuss] An idea ... MTR + IRS

Hi,

This morning Scott mentioned that he would like to use IRS to shut down 
all protocols and just be able to write to RIB. Now James said that he 
would like to get a network topology as "every OpenFlow controller 
requires this"

Both connected together resulted in an idea of using 
multi-topology-routing where your base topology discovers physical link 
connectivity graph while other topologies could be programmed by 
external entities example: OF controllers or any other external to 
routers network intelligence oracles to deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed 
"write to RIB" set of protocols ? Would you support OF 1.3 even if one 
would be happy to lock such topologies only to software/programmable 
switching paths ?

Best rgs,
R.
_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss

Sender: [email-masked]
Date: Tue, 7 Aug 2012 14:34:27 -0400
From: "Y. Richard Yang" <[email-masked]>
To: Noel Chiappa <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

--f46d0446312c90f8b604c6b13e5d
Content-Type: text/plain; charset=ISO-8859-1

On Tue, Aug 7, 2012 at 11:15 AM, Noel Chiappa <[email-masked]>wrote:

>     > From: "Y. Richard Yang" <[email-masked]>
>
>     > Glad that you also like the idea of different levels of details of
> the
>     > network topology. If the ALTO Server is given a detailed topology
>     > ... we can offer multiple topology operators/aggregators to explore
> the
>     > detailed topology, according to need and policy.
>
> Too bad we have a routing architecture that deals (as its fundamental
> currency) in destination tables, rather than topology - and, in particular,
> in a multi-level representation of the toplogy. Then all this stuff would
> just fall out naturally.
>
>
It appears to have increasing efforts focusing on building
abstractions/network
computations based on topology. Hope that it moves somewhere. We are finding
more benefits of using topology-based network routing/control, e.g.,
McNettle
(Multi-core Nettle), an SDN controlled being developed here, uses STM to
manage
topology in a highly concurrent controller and achieves pretty good
scalability.

> (And if I sound somewhat cranky, perhaps people will forgive me - although
> I
> expect not that many on this list will know what I'm implicitly referring
> to.)
>
>
>     > There are studies on representation of multi-level graphs that we can
>     > try to take advantage of. This can be a subject for the group to
> explore.
>
> There's a PhD thesis which is relevant to this area (since part of it is
> about clustering, i.e. in representing an area of the graph without full
> detail, one has to decide where to set the boundaries of said part):
>
>   Jacob Hagouel, "Issues in Routing for Large and Dynamic Netoworks",
>   Columbia University, 1983
>
> A lot of it is irrelevant (to me, at least), since it's talking about
> distributed path computation (which I have long since concluded is 'buggy
> whip' technology), but the clustering, etc, content is good.
>

Thanks a lot for the pointer. Definitely will read.

Richard

>
>         Noel
>

--f46d0446312c90f8b604c6b13e5d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<br><br><div class="gmail_quote">On Tue, Aug 7, 2012 at 11:15 AM, Noel Chiappa <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">
    &gt; From: &quot;Y. Richard Yang&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<div class="im"><br>
    &gt; Glad that you also like the idea of different levels of details of the<br>
    &gt; network topology. If the ALTO Server is given a detailed topology<br>
</div>    &gt; ... we can offer multiple topology operators/aggregators to explore the<br>
<div class="im">    &gt; detailed topology, according to need and policy.<br>
<br>
</div>Too bad we have a routing architecture that deals (as its fundamental<br>
currency) in destination tables, rather than topology - and, in particular,<br>
in a multi-level representation of the toplogy. Then all this stuff would<br>
just fall out naturally.<br>
<br></blockquote><div> </div><div>It appears to have increasing efforts focusing on building abstractions/network</div><div>computations based on topology. Hope that it moves somewhere. We are finding</div><div>more benefits of using topology-based network routing/control, e.g., McNettle</div>
<div>(Multi-core Nettle), an SDN controlled being developed here, uses STM to manage</div><div>topology in a highly concurrent controller and achieves pretty good scalability.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

(And if I sound somewhat cranky, perhaps people will forgive me - although I<br>
expect not that many on this list will know what I&#39;m implicitly referring to.)<br>
<div class="im"><br>
<br>
    &gt; There are studies on representation of multi-level graphs that we can<br>
    &gt; try to take advantage of. This can be a subject for the group to explore.<br>
<br>
</div>There&#39;s a PhD thesis which is relevant to this area (since part of it is<br>
about clustering, i.e. in representing an area of the graph without full<br>
detail, one has to decide where to set the boundaries of said part):<br>
<br>
  Jacob Hagouel, &quot;Issues in Routing for Large and Dynamic Netoworks&quot;,<br>
  Columbia University, 1983<br>
<br>
A lot of it is irrelevant (to me, at least), since it&#39;s talking about<br>
distributed path computation (which I have long since concluded is &#39;buggy<br>
whip&#39; technology), but the clustering, etc, content is good.<br></blockquote><div><br></div><div>Thanks a lot for the pointer. Definitely will read.</div><div><br></div><div>Richard</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<span class="HOEnZb"><font color="#888888"><br>
        Noel<br>
</font></span></blockquote></div><br>

--f46d0446312c90f8b604c6b13e5d--

To: [email-masked]
Date: Tue,  7 Aug 2012 11:15:29 -0400 (EDT)
From: [email-masked] (Noel Chiappa)
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

    > From: "Y. Richard Yang" <[email-masked]>

    > Glad that you also like the idea of different levels of details of the
    > network topology. If the ALTO Server is given a detailed topology
    > ... we can offer multiple topology operators/aggregators to explore the
    > detailed topology, according to need and policy.

Too bad we have a routing architecture that deals (as its fundamental
currency) in destination tables, rather than topology - and, in particular,
in a multi-level representation of the toplogy. Then all this stuff would
just fall out naturally.

(And if I sound somewhat cranky, perhaps people will forgive me - although I
expect not that many on this list will know what I'm implicitly referring to.)

    > There are studies on representation of multi-level graphs that we can
    > try to take advantage of. This can be a subject for the group to explore.

There's a PhD thesis which is relevant to this area (since part of it is
about clustering, i.e. in representing an area of the graph without full
detail, one has to decide where to set the boundaries of said part):

  Jacob Hagouel, "Issues in Routing for Large and Dynamic Netoworks",
  Columbia University, 1983

A lot of it is irrelevant (to me, at least), since it's talking about
distributed path computation (which I have long since concluded is 'buggy
whip' technology), but the clustering, etc, content is good.

	Noel

Date: Tue, 7 Aug 2012 13:16:54 +0200
From: Volker Hilt <[email-masked]>
To: "Y. Richard Yang" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, Thomas Nadeau <[email-masked]>, stefano previdi <[email-masked]>
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Richard,
>>
>> I like the idea of enabling an ALTO server to offer different levels
>> of details. This will enable a server to tailor responses to the
>> specific client. It will add complexity as the ALTO server itself will
>> have to maintain the most complex topology it is offering and will
>> have to keep this topology up to date. But this is an interesting
>> question for discussion in the WG.
>>
> Glad that you also like the idea of different levels of details of the
> network topology. If the ALTO Server is given a detailed topology
> (constructed from multiple sources, such as routing feed, LSP feed,
> configuration files), we can offer multiple topology
> operators/aggregators to explore the detailed topology, according to
> need and policy. A simple example operator is level (i.e., hierarchy
> such as at the area level), but one might specify other operators (e.g.,
> fisheye focus). There are studies on representation of multi-level
> graphs that we can try to take advantage of. This can be a subject for
> the group to explore.
>
Yes, I agree - this is an interesting area to explore. Another operator 
could be a view for a specific use, e.g., a view for CDN use. The 
operator can then populate this view with the desired abstraction level 
and policy.

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

Volker

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

Date: Mon, 6 Aug 2012 20:39:11 +0200
From: Hannes Gredler <[email-masked]>
To: "Y. Richard Yang" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, James Kempf <[email-masked]>, Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>, [email-masked]
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

richard,

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

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

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

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

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

/hannes

Date: Mon, 06 Aug 2012 11:15:48 -0700
From: Greg Bernstein <[email-masked]>
To: [email-masked]
Subject: [irs-discuss] subscribe

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

Date: Mon, 06 Aug 2012 11:09:52 -0700
From: Greg Bernstein <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: [email-masked], Volker Hilt <[email-masked]>, [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, "Y. Richard Yang" <[email-masked]>
Subject: Re: [irs-discuss] [alto]  About ALTO Vs. BGP-LS

This is a multi-part message in MIME format.
--------------080305080401020808030000
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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

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

Cheers

Greg B.

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

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

--------------080305080401020808030000
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

</pre>
  </body>
</html>

--------------080305080401020808030000--

Date: Mon, 06 Aug 2012 10:49:38 -0700
From: Greg Bernstein <[email-masked]>
To: "Y. Richard Yang" <[email-masked]>
Cc: [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] [alto]  About ALTO Vs. BGP-LS

This is a multi-part message in MIME format.
--------------090209040004060208090600
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

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

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

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

Best Regards
Greg B.

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

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

--------------090209040004060208090600
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

</pre>
  </body>
</html>

--------------090209040004060208090600--

Date: Fri, 3 Aug 2012 19:57:07 -0400
From: Alia Atlas <[email-masked]>
To: "Y. Richard Yang" <[email-masked]>
Cc: [email-masked], Volker Hilt <[email-masked]>, [email-masked], [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, Thomas Nadeau <[email-masked]>, stefano previdi <[email-masked]>
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

--20cf301cc2e21d4fbf04c6654988
Content-Type: text/plain; charset=ISO-8859-1

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

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

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

--20cf301cc2e21d4fbf04c6654988
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<p>I strongly agree that we need to start collecting the use-cases for multiple abstraction levels as well as physical/virtual/private.</p>
<p>Alia</p>
<div class="gmail_quote">On Aug 3, 2012 4:51 PM, &quot;Y. Richard Yang&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Volker,<br>
<br>
On 8/3/12 12:02 PM, Volker Hilt wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I believe that the capability to provide a simplified view on the network topology to an application is a key feature rather than a bug. Applications that want to have a view on network topology don&#39;t need need a fine grained view on the topology in most casts and benefit from having an abstracted view. This will simplify processing for the application and enables providers to control the exposure of details. <br>

</blockquote>
Agreed.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We&#39;ve seen some numbers for topology data sizes in the incremental updates presentation in the ALTO meeting, which provide some insights into the amounts of data needed for different topology sizes.<br>
<br>
I like the idea of enabling an ALTO server to offer different levels of details. This will enable a server to tailor responses to the specific client. It will add complexity as the ALTO server itself will have to maintain the most complex topology it is offering and will have to keep this topology up to date. But this is an interesting question for discussion in the WG.<br>

<br>
</blockquote>
Glad that you also like the idea of different levels of details of the network topology. If the ALTO Server is given a detailed topology (constructed from multiple sources, such as routing feed, LSP feed, configuration files), we can offer multiple topology operators/aggregators to explore the detailed topology, according to need and policy. A simple example operator is level (i.e., hierarchy such as at the area level), but one might specify other operators (e.g., fisheye focus). There are studies on representation of multi-level graphs that we can try to take advantage of. This can be a subject for the group to explore.<br>

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

--20cf301cc2e21d4fbf04c6654988--

Date: Fri, 03 Aug 2012 13:50:33 -0700
From: "Y. Richard Yang" <[email-masked]>
To: Volker Hilt <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, Thomas Nadeau <[email-masked]>, "Y. Richard Yang" <[email-masked]>, stefano previdi <[email-masked]>
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Hi Volker,

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

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

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

Cheers,

Richard

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

Date: Fri, 3 Aug 2012 12:02:31 -0700
From: Volker Hilt <[email-masked]>
To: "Y. Richard Yang" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, Thomas Nadeau <[email-masked]>, stefano previdi <[email-masked]>
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Stefano, Richard,

great discussion.

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

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

Cheers,

Volker

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

Date: Fri, 03 Aug 2012 11:46:12 -0700
From: "Y. Richard Yang" <[email-masked]>
To: Susan Hares <[email-masked]>, [email-masked]
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, Thomas Nadeau <[email-masked]>, "Y. Richard Yang" <[email-masked]>, stefano previdi <[email-masked]>
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Hi,

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

Thanks.

Richard

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

From: Susan Hares <[email-masked]>
To: "Y. Richard Yang" <[email-masked]>, stefano previdi <[email-masked]>
Date: Fri, 3 Aug 2012 18:24:30 +0000
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Richard:

Could you cross-post this note to the [email-masked] list. The BGP-LS draft is being considered for WG adoption. I think this perspective would help the idr WG. 

Thank you, 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: Friday, August 03, 2012 11:04 AM
To: stefano previdi
Cc: Thomas Nadeau; James Kempf; IETF ALTO; [email-masked]; [email-masked]
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Hi Stefano,

Good post! I added the ALTO mailing list, given the relevance. I hope 
that this is OK cross posting.

First, a few comments on ALTO:

View granularity:

- ALTO currently defines two abstract network topology data structures: 
Network Map and Cost Map(s). More link-state oriented maps (graphs), 
with aggregations and transformations, can be added efficiently to ALTO. 
Some initial efforts are already on the way (e.g., see the graph 
representation proposal at page 9: 
http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, 
I see a natural next-step is for ALTO to provide a link-state view to 
external entities.

- It is a good comment on the level of details that ALTO should 
delivery. This is a good question for the ALTO working group and the 
community to discuss. I feel that ALTO should provide multi-levels of 
granularity of views, and we should discuss in the working group.

Pull vs push delivery mechanism:

- There are more discussions on adding the incremental update in ALTO. 
Multiple mechanisms have been discussed. I feel that it is the right 
direction for ALTO.

Now let me understand the deployment model of BGP-LS. Your explanation 
on the issues of acquiring routing state is excellent. Let me start by 
understanding more details on the deployment model of BGP-LS inside a 
network:

- A set N_igp of BGP-LS instances are deployed to collect IGP info. You 
need multiple instances because IGP needs direct connectivity 
(adjacency). Each instance here receives (potentially multiple) IGP 
updates and streams (relays) to an another (remote) entity, which I 
assume is a master BGP-LS instance. So each of these N_igp instances is 
IGP-in and BGP-LS out. This appears to be shown in Figure 1 of 
draft-gredler-idr-ls-distribution.

- A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You 
also may need multiple instances because the network does not want to 
see aggregated states but raw states. These instances will feed to the 
master BGP-LS as well.

- The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some 
direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to 
use: for example, an ALTO Server transforms/aggregates the feed to 
generate ALTO views (maps and graphs), and an PCE uses the feed to 
maintain its TED. One could even imagine that ALTO builds a detailed TED 
and feeds to PCE, but this beyond the scope of this discussion. The 
master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the 
master BGP-LS does not push to any other entities and simply maintains 
an internal DB for others to query.

Do I understand it correctly?

Now, we can take a look at more specifics of BGP-LS.

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

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

Thanks!

Richard

On 8/2/12 11:54 PM, stefano previdi wrote:
> All,
>
> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few
> things:
>
> ALTO has been designed in order to deliver to applications (through
> http/json):
>
> 1. two maps representing the network topology in an abstracted view
>     (or set of views through multiple maps). The map does not include
>     the details of a link-state database and therefore have little use
>     for any element that would need to retrieve from the network the
>     detailed/complete network layer topology, for example: link
>     addresses or link BW resources, etc. IOW: ALTO maps do not have
>     the granularity of a link-state database and ALTO protocol is not
>     designed to deliver such details.
>
> and/or
>
> 2. Ranking services where a client sends a bunch of IP addresses in
>     a message and the ALTO server replies by ranking these addresses
>     based on their topological/network distance (or whatever criteria
>     the ALTO server has been configured for). This is called: Endpoint
>     Cost Service.
>
> When using ALTO maps, and the ALTO protocol being http/pull based,
> there's no such concept of unsolicited routing updates. An ALTO
> client is typically a browser that will pull the maps from an ALTO
> server using http. The ALTO server will make no effort to ensure the
> client has the latest view of the topology (i.e.: It's the role of the
> client to poll for new maps time to time).
>
> Now, in order for an ALTO server to deliver Maps or Ranking services,
> it needs to build some form of topology and in order to achieve this,
> it needs somehow to be fed by either the operator (configuration) or
> to receive dynamically topology information from the network (e.g.:
> ISIS/OSPF/BGP).
>
> Here we had two options:
> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
>     to ABRs or L1L2 routers in each area so to retrieve the LSDB from
>     each area. In practice I know no SP willing/accepting to open their
>     IGP to an ALTO server. Also, IGP requires direct connectivity
>     (adjacency) so from an operation point of view is complex and not
>     desired.
> 2. Use a database distribution protocol running on top of a reliable
>     transport layer that would allow an ALTO server to connect to a
>     _single_ and _remote_ Route Reflector (i.e.: no need to be directly
>     connected) and grab the whole network topology that will be updated
>     using standard routing protocol mechanisms (i.e.: routing updates)
>     and that would allow the operator to control (through policies and
>     filters) what to distribute and to which server.
>
>     Benefits: single (or dual at most for redundancy) connection for
>     the ALTO server (rather than having a direct adjacency with each
>     ABR) and, from the operator perspective, single point of
>     distribution of network topology (easier to apply policies and
>     control what you deliver). This is what BGP-LS is about.
>
> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
> link-state and, more generically, any type of topology information.
> The draft specifies NLRI and attributes that map whatever you can
> find in a link-state database.
>
> We currently have draft-gredler-idr-ls-distribution in the process
> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting
> good support). We also have 3 implementations of BGP-LS.
>
> Deployment-wise: BGP-LS is not yet deployed, however, we already have
> deployments (I know at least two) where an ALTO server retrieves IP
> prefix information from remote BGP RRs (for ipv4). The same scheme
> will be used once BGP-LS will be deployed (so to say that it is not
> something that we invented after a couple of beers but corresponds to
> requirements for delivering network services to upper layers while
> still controlling efficiently what you distribute, to whom and in
> which form (note that, often, beers are anyway part of the process).
>
> More information here:
> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
> http://tools.ietf.org/html/draft-ietf-alto-protocol-12
>
> Hope this helps.
>
> s.
>
>
>
> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
>> Tom,
>>
>>> I agree that one of the top work items for this effort should be a
>>> standardized topology function, and one that is accessible via a
>>> non-routing protocol.
>> So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS.
>>
>> However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation.
>>
>> The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;)
>>
>> R.
>>
>>> 	I agree that one of the top work items for this effort should be a
>>> standardized topology function, and one that is accessible via a
>>> non-routing protocol.  While not exactly "low hanging fruit", it is
>>> something that (to me) is a clear work item with clear goals that should
>>> be tackled straight away.
>>>
>>> 	--Tom
>>>
>>>
>>>
>>> On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>>>
>>>> So after seeing part of Alia's talk this morning (I had to leave in the
>>>> middle unfortunately), I'd like to make a couple suggestions. There were
>>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>>> think to make tangible progress, the work needs to be focussed on a small
>>>> subset that would be of immediate interest and usability.
>>>>
>>>> There are a couple areas that suggest themselves, but one that would be
>>>> useful in work that I've been involved in is a standardized format for
>>>> network topology representation and a protocol for exchanging it. The
>>>> Onix OpenFlow controller has a network information base with a
>>>> specialized format for network topology, and every OpenFlow controller
>>>> requires this. Having a standardized way to represent it might foster a
>>>> common topology database package. Another application is network
>>>> management. Every network management system needs some kind of topology
>>>> representation. Finally, though I am not an expert in PCE construction,
>>>> it would seem to me that a PCE would need some kind of topology
>>>> representation in order to perform path calculations. Having a way,for
>>>> example, for the OpenFlow controller and the PCE to exchange topology
>>>> information would be really useful.  I would say to start with physical
>>>> topology because that is fundamental, but make the format flexible enough
>>>> to support
>>>> virtual topology representation.
>>>>
>>>> 			jak
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

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

Date: Fri, 3 Aug 2012 14:22:54 -0400
From: Alia Atlas <[email-masked]>
To: "Jan Medved (jmedved)" <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Jan,

I think that the topology data-model for IRS would not be confined to
what can be learned from a single router.  It could be partially
populated from a single router.  An application can talk to multiple
routers to learn the topology; in the same way an application could
need to install static routes at multiple routers.

A topology-server could talk to as many devices (routers, databases,
etc) as necessary to completely fill out the topology data-model.

An area that would be quite fruitful to discuss is the multiple
abstraction layers as well as, perhaps, some of the physical layers
and attributes that would be good to include.

I'd really like to get some productive brainstorming done on use-cases
related to the topology data-model.

I think we might be able to just have a single use-cases and
requirements draft in this area - but we'll have to see how large that
gets.

I know that many of us are quite eager to get to the topology
data-model and how it would be populated (and BGP-LS is probably a
good way for some of the information), but getting on the same page as
far as use-cases and requirements (while quietly writing data-models
in the background for sanity-checking) seems like a good first step to
me.

Alia

On Fri, Aug 3, 2012 at 1:33 AM, Jan Medved (jmedved) <[email-masked]> wrote:
> Tom,
>
> On 8/2/12 4:42 PM, "Thomas Nadeau" <[email-masked]> wrote:
>
>>
>>
>>On 8/2/12 4:29 PM, "Robert Raszuk" <[email-masked]> wrote:
>>
>>>Tom,
>>>
>>> > I agree that one of the top work items for this effort should be a
>>> > standardized topology function, and one that is accessible via a
>>> > non-routing protocol.
>>>
>>>So if the requirement is to have topology export via non-routing
>>>protocol then I think we should seriously revisit or repackage the
>>>draft-gredler-idr-ls-distribution-01 which works for for both OSPF and
>>>ISIS.
>>
>>       Cool.
>>
>>
>>>However before that let's really understand the requirement why it must
>>>be exported via non-routing protocol .... Keep in mind that just to
>>>parse BGP UPDATE messages and retrieve interesting pieces out it it
>>>requires very little code rather then full BGP implementation.
>
> Agreed.
>
>>
>>       That seemed to be one of the agreements that came out of the session
>>today.
>
> Can you give more background?
>
> I don't think it's as straightforward. BGP-LS implements a network-wide
> model (data schema), while the scope of IRS is a single node (IMO as it
> should be). A node's local IGP and BGP databases do not provide the view
> of the entire network topology. To get the whole topology, multiple
> routers need to be queried, and the topology needs to be 'stitched'
> together. This can either be done in an external node (an ALTO Server, for
> example), or in a router.
>
> If the 'stitching' is done in an external server, would it mean that the
> scope of IRS is extended to entities other than routers?
>
> If the 'stitching' is done at a router, then the router would have to
> collect the topology data from other routers - using BGP-LS, for example
> ;-) The topology export would then basically have to provide access to the
> BGP-LS database through some adaptation function. I wonder what's the gain
> in this case...
>
>>
>>       --Tom
>>
>
> Thanks,
> Jan
>
>>
>>>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Fri, 3 Aug 2012 14:16:21 -0400
From: Alia Atlas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: James Kempf <[email-masked]>, "Jan Medved \(jmedved\)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Just a reminder that while BGP-LS is certainly of interest for IRS,
more focused discussion on it for now probably belongs on the IDR
mailing list...

What would be great to discuss here are the use-cases that aren't
satisfied by BGP-LS...

Alia

On Fri, Aug 3, 2012 at 2:09 PM, Susan Hares <[email-masked]> wrote:
> Jan:
>
> The real question about this data is the operational questions and aids? For example,
>
> a) Did the implementations allow ISIS topology to be easily put in this new BGP draft,
> b) Do the implementations have filters to prevent this new BGP AFI/SAFI being put in v4/v6 AFI/SAFI BGPs,
> c) Is it wise to run both in the same process? Or should it be recommended to have two processes?
> d) Have implementers or Service providers tried a test case about putting the ISIS topology into the base protocol.
> f) What type of special failure cases can the RR have?
>
> Summary... It's possible, but do implementations have knobs (in any form) to prevent disaster.
>
> Sue
>
>
> -----Original Message-----
> From: Jan Medved (jmedved) [mailto:[email-masked]]
> Sent: Thursday, August 02, 2012 9:11 PM
> To: Susan Hares; James Kempf; [email-masked]
> Cc: [email-masked]
> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
>
> Sue,
>
> On 8/2/12 6:15 PM, "Susan Hares" <[email-masked]> wrote:
>
>>James:
>>
>>BGP and ISIS may have overkill - or it may be just right.  Realize - this
>>information does not come for free.
>
> Agreed.
>
> It costs to extract the topology information from the router, and it costs
> to process it a the client. A routing protocol is a good low cost
> interface to get topology data out of a router, since routing is one of
> the things that routers are optimized for.
>
> Now, if a client does not want to listen to BGP Updates (which is not that
> difficult to implement, as Robert pointed out), we can have an
> intermediary, such an ALTO Server, which will receive routing protocol
> updates and provide the topology to clients in an easier-to-digest format.
>
>>
>>You are running BGP sessions across the network passing this information.
>>All of the routers must be configured and instrumented separately from
>>the regular BGP. ISIS uploaded into these BGP sessions and distributed.
>
> Not necessarily. In a single-area IGP, a single BGP-LS speaker listening
> to IGP updates can retrieve the IGP topology for the whole network. Other
> BGP Speakers in the network do not need to be BGP-LS enabled at all.
>
> If we want to retrieve a complete topology of a multi-area IGP network,
> there must be an IGP listener in each IGP area. If a client wants to use
> BGP-LS to retrieve the IGP topology from the network, it can set up a
> BGP-LS session to each of the IGP listeners (in each area). Alternatively,
> we can use a Route Reflector to collect the topology data from all BGP-LS
> Speakers; then, the client only needs to establish a single session to the
> Route Reflector. Also, the Route Reflector can service multiple clients.
> Note that in this case there too is only a small set of routers than need
> to be BGP-LS enabled.
>
> Basically, we leverage existing BGP mechanisms to collect the topology
> data from the entire network. We can leverage an existing Route Reflector,
> or we can dedicate a Route Reflector just for BGP-LS. Talking to multiple
> operators, they prefer the latter option.
>
>>
>>Please ask the authors about the details of their implementations.
>
> Sure, if more details are required, we'll be glad to discuss :-)
>
>>
>>Sue
>>
> Thanks,
> Jan
>
>>
>>-----Original Message-----
>>From: James Kempf [mailto:[email-masked]]
>>Sent: Thursday, August 02, 2012 4:53 PM
>>To: Susan Hares; [email-masked]
>>Cc: [email-masked]
>>Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>>
>>I'll have to take a look at draft-grendler, I am not familiar with it.
>>
>>The particular use cases I'm interested in are NMS and OpenFlow
>>controller type applications where some centralized entity wants
>>information on the topology for managing the elements in a way that
>>allows policies to be expressed over the network as a whole and
>>translated into specific element management polices by the controller/NMS
>>system. The topology data base must be populated somehow, obviously, but
>>I assume that would be part of the work (perhaps draft-grendler describes
>>this). The physical topology won't be exported outside an operator's
>>domain since managing the physical infrastructure is under the purview of
>>the operator. If the topology database supports expressing virtual
>>topologies (which I believe it should) the operator could expose virtual
>>topologies to the customers of the virtual networks, and allow them the
>>ability to manage their virtual slices.
>>
>>Make sense?
>>
>>                       jak
>>
>>> -----Original Message-----
>>> From: Susan Hares [mailto:[email-masked]]
>>> Sent: Thursday, August 02, 2012 4:30 PM
>>> To: [email-masked]; James Kempf
>>> Cc: [email-masked]
>>> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>>>
>>> James:
>>>
>>> This is the full detailed routes.  However, will every ISP
>>> share it's ISIS topology.
>>>
>>> Sue
>>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Robert Raszuk
>>> Sent: Thursday, August 02, 2012 4:21 PM
>>> To: James Kempf
>>> Cc: [email-masked]
>>> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
>>>
>>> Hi James,
>>>
>>> On the topic of topology export it is my understanding that
>>> we do already have a solution which in fact even authors of
>>> IRS framework support and are putting under their umbrella.
>>>
>>> That is:
>>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01
>>>
>>> The draft as standards track document defines the topology
>>> export standard in form of link and node NLRIs with bunch of TLVs.
>>>
>>> So the key aspect would be to see what is missing and if
>>> something is missing in the space of topology export to
>>> evaluate if this solution by principle can be extended to
>>> accommodate it.
>>>
>>> Best,
>>> R.
>>>
>>>
>>> > So after seeing part of Alia's talk this morning (I had to leave in
>>> > the middle unfortunately), I'd like to make a couple suggestions.
>>> > There were a lot of ideas presented in the talk, enough for
>>> an entire
>>> > IETF Area. I think to make tangible progress, the work needs to be
>>> > focussed on a small subset that would be of immediate interest and
>>> > usability.
>>> >
>>> > There are a couple areas that suggest themselves, but one
>>> that would
>>> > be useful in work that I've been involved in is a
>>> standardized format
>>> > for network topology representation and a protocol for
>>> exchanging it.
>>> > The Onix OpenFlow controller has a network information base with a
>>> > specialized format for network topology, and every OpenFlow
>>> controller
>>> > requires this. Having a standardized way to represent it
>>> might foster
>>> > a common topology database package. Another application is network
>>> > management. Every network management system needs some kind of
>>> > topology representation. Finally, though I am not an expert in PCE
>>> > construction, it would seem to me that a PCE would need
>>> some kind of
>>> > topology representation in order to perform path
>>> calculations. Having
>>> > a way,for example, for the OpenFlow controller and the PCE
>>> to exchange
>>> > topology information would be really useful.
>>> > I would say to start with physical topology because that is
>>> > fundamental, but make the format flexible enough to support virtual
>>> > topology representation.
>>> >
>>> > jak _______________________________________________ irs-discuss
>>> > mailing list [email-masked]
>>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>>> >
>>> >
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: "Jan Medved (jmedved)" <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 3 Aug 2012 18:09:46 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Jan:

The real question about this data is the operational questions and aids? For example, 

a) Did the implementations allow ISIS topology to be easily put in this new BGP draft,
b) Do the implementations have filters to prevent this new BGP AFI/SAFI being put in v4/v6 AFI/SAFI BGPs,
c) Is it wise to run both in the same process? Or should it be recommended to have two processes? 
d) Have implementers or Service providers tried a test case about putting the ISIS topology into the base protocol. 
f) What type of special failure cases can the RR have? 

Summary... It's possible, but do implementations have knobs (in any form) to prevent disaster.  

Sue 

-----Original Message-----
From: Jan Medved (jmedved) [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 9:11 PM
To: Susan Hares; James Kempf; [email-masked]
Cc: [email-masked]
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Sue,

On 8/2/12 6:15 PM, "Susan Hares" <[email-masked]> wrote:

>James:
>
>BGP and ISIS may have overkill - or it may be just right.  Realize - this
>information does not come for free.

Agreed. 

It costs to extract the topology information from the router, and it costs
to process it a the client. A routing protocol is a good low cost
interface to get topology data out of a router, since routing is one of
the things that routers are optimized for.

Now, if a client does not want to listen to BGP Updates (which is not that
difficult to implement, as Robert pointed out), we can have an
intermediary, such an ALTO Server, which will receive routing protocol
updates and provide the topology to clients in an easier-to-digest format.

>
>You are running BGP sessions across the network passing this information.
>All of the routers must be configured and instrumented separately from
>the regular BGP. ISIS uploaded into these BGP sessions and distributed.

Not necessarily. In a single-area IGP, a single BGP-LS speaker listening
to IGP updates can retrieve the IGP topology for the whole network. Other
BGP Speakers in the network do not need to be BGP-LS enabled at all.

If we want to retrieve a complete topology of a multi-area IGP network,
there must be an IGP listener in each IGP area. If a client wants to use
BGP-LS to retrieve the IGP topology from the network, it can set up a
BGP-LS session to each of the IGP listeners (in each area). Alternatively,
we can use a Route Reflector to collect the topology data from all BGP-LS
Speakers; then, the client only needs to establish a single session to the
Route Reflector. Also, the Route Reflector can service multiple clients.
Note that in this case there too is only a small set of routers than need
to be BGP-LS enabled.

Basically, we leverage existing BGP mechanisms to collect the topology
data from the entire network. We can leverage an existing Route Reflector,
or we can dedicate a Route Reflector just for BGP-LS. Talking to multiple
operators, they prefer the latter option.

>
>Please ask the authors about the details of their implementations.

Sure, if more details are required, we'll be glad to discuss :-)

>
>Sue 
>
Thanks,
Jan

>
>-----Original Message-----
>From: James Kempf [mailto:[email-masked]]
>Sent: Thursday, August 02, 2012 4:53 PM
>To: Susan Hares; [email-masked]
>Cc: [email-masked]
>Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>
>I'll have to take a look at draft-grendler, I am not familiar with it.
>
>The particular use cases I'm interested in are NMS and OpenFlow
>controller type applications where some centralized entity wants
>information on the topology for managing the elements in a way that
>allows policies to be expressed over the network as a whole and
>translated into specific element management polices by the controller/NMS
>system. The topology data base must be populated somehow, obviously, but
>I assume that would be part of the work (perhaps draft-grendler describes
>this). The physical topology won't be exported outside an operator's
>domain since managing the physical infrastructure is under the purview of
>the operator. If the topology database supports expressing virtual
>topologies (which I believe it should) the operator could expose virtual
>topologies to the customers of the virtual networks, and allow them the
>ability to manage their virtual slices.
>
>Make sense?
>
>			jak  
>
>> -----Original Message-----
>> From: Susan Hares [mailto:[email-masked]]
>> Sent: Thursday, August 02, 2012 4:30 PM
>> To: [email-masked]; James Kempf
>> Cc: [email-masked]
>> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>> 
>> James:
>> 
>> This is the full detailed routes.  However, will every ISP
>> share it's ISIS topology.
>> 
>> Sue 
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Robert Raszuk
>> Sent: Thursday, August 02, 2012 4:21 PM
>> To: James Kempf
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
>> 
>> Hi James,
>> 
>> On the topic of topology export it is my understanding that
>> we do already have a solution which in fact even authors of
>> IRS framework support and are putting under their umbrella.
>> 
>> That is: 
>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01
>> 
>> The draft as standards track document defines the topology
>> export standard in form of link and node NLRIs with bunch of TLVs.
>> 
>> So the key aspect would be to see what is missing and if
>> something is missing in the space of topology export to
>> evaluate if this solution by principle can be extended to
>> accommodate it.
>> 
>> Best,
>> R.
>> 
>> 
>> > So after seeing part of Alia's talk this morning (I had to leave in
>> > the middle unfortunately), I'd like to make a couple suggestions.
>> > There were a lot of ideas presented in the talk, enough for
>> an entire 
>> > IETF Area. I think to make tangible progress, the work needs to be
>> > focussed on a small subset that would be of immediate interest and
>> > usability.
>> >
>> > There are a couple areas that suggest themselves, but one
>> that would 
>> > be useful in work that I've been involved in is a
>> standardized format
>> > for network topology representation and a protocol for
>> exchanging it.
>> > The Onix OpenFlow controller has a network information base with a
>> > specialized format for network topology, and every OpenFlow
>> controller 
>> > requires this. Having a standardized way to represent it
>> might foster 
>> > a common topology database package. Another application is network
>> > management. Every network management system needs some kind of
>> > topology representation. Finally, though I am not an expert in PCE
>> > construction, it would seem to me that a PCE would need
>> some kind of 
>> > topology representation in order to perform path
>> calculations. Having
>> > a way,for example, for the OpenFlow controller and the PCE
>> to exchange 
>> > topology information would be really useful.
>> > I would say to start with physical topology because that is
>> > fundamental, but make the format flexible enough to support virtual
>> > topology representation.
>> >
>> > jak _______________________________________________ irs-discuss
>> > mailing list [email-masked]
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> >
>> >
>> 
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Fri, 03 Aug 2012 11:03:57 -0700
From: "Y. Richard Yang" <[email-masked]>
To: stefano previdi <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, IETF ALTO <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS

Hi Stefano,

Good post! I added the ALTO mailing list, given the relevance. I hope 
that this is OK cross posting.

First, a few comments on ALTO:

View granularity:

- ALTO currently defines two abstract network topology data structures: 
Network Map and Cost Map(s). More link-state oriented maps (graphs), 
with aggregations and transformations, can be added efficiently to ALTO. 
Some initial efforts are already on the way (e.g., see the graph 
representation proposal at page 9: 
http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence, 
I see a natural next-step is for ALTO to provide a link-state view to 
external entities.

- It is a good comment on the level of details that ALTO should 
delivery. This is a good question for the ALTO working group and the 
community to discuss. I feel that ALTO should provide multi-levels of 
granularity of views, and we should discuss in the working group.

Pull vs push delivery mechanism:

- There are more discussions on adding the incremental update in ALTO. 
Multiple mechanisms have been discussed. I feel that it is the right 
direction for ALTO.

Now let me understand the deployment model of BGP-LS. Your explanation 
on the issues of acquiring routing state is excellent. Let me start by 
understanding more details on the deployment model of BGP-LS inside a 
network:

- A set N_igp of BGP-LS instances are deployed to collect IGP info. You 
need multiple instances because IGP needs direct connectivity 
(adjacency). Each instance here receives (potentially multiple) IGP 
updates and streams (relays) to an another (remote) entity, which I 
assume is a master BGP-LS instance. So each of these N_igp instances is 
IGP-in and BGP-LS out. This appears to be shown in Figure 1 of 
draft-gredler-idr-ls-distribution.

- A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You 
also may need multiple instances because the network does not want to 
see aggregated states but raw states. These instances will feed to the 
master BGP-LS as well.

- The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some 
direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to 
use: for example, an ALTO Server transforms/aggregates the feed to 
generate ALTO views (maps and graphs), and an PCE uses the feed to 
maintain its TED. One could even imagine that ALTO builds a detailed TED 
and feeds to PCE, but this beyond the scope of this discussion. The 
master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the 
master BGP-LS does not push to any other entities and simply maintains 
an internal DB for others to query.

Do I understand it correctly?

Now, we can take a look at more specifics of BGP-LS.

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

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

Thanks!

Richard

On 8/2/12 11:54 PM, stefano previdi wrote:
> All,
>
> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few
> things:
>
> ALTO has been designed in order to deliver to applications (through
> http/json):
>
> 1. two maps representing the network topology in an abstracted view
>     (or set of views through multiple maps). The map does not include
>     the details of a link-state database and therefore have little use
>     for any element that would need to retrieve from the network the
>     detailed/complete network layer topology, for example: link
>     addresses or link BW resources, etc. IOW: ALTO maps do not have
>     the granularity of a link-state database and ALTO protocol is not
>     designed to deliver such details.
>
> and/or
>
> 2. Ranking services where a client sends a bunch of IP addresses in
>     a message and the ALTO server replies by ranking these addresses
>     based on their topological/network distance (or whatever criteria
>     the ALTO server has been configured for). This is called: Endpoint
>     Cost Service.
>
> When using ALTO maps, and the ALTO protocol being http/pull based,
> there's no such concept of unsolicited routing updates. An ALTO
> client is typically a browser that will pull the maps from an ALTO
> server using http. The ALTO server will make no effort to ensure the
> client has the latest view of the topology (i.e.: It's the role of the
> client to poll for new maps time to time).
>
> Now, in order for an ALTO server to deliver Maps or Ranking services,
> it needs to build some form of topology and in order to achieve this,
> it needs somehow to be fed by either the operator (configuration) or
> to receive dynamically topology information from the network (e.g.:
> ISIS/OSPF/BGP).
>
> Here we had two options:
> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
>     to ABRs or L1L2 routers in each area so to retrieve the LSDB from
>     each area. In practice I know no SP willing/accepting to open their
>     IGP to an ALTO server. Also, IGP requires direct connectivity
>     (adjacency) so from an operation point of view is complex and not
>     desired.
> 2. Use a database distribution protocol running on top of a reliable
>     transport layer that would allow an ALTO server to connect to a
>     _single_ and _remote_ Route Reflector (i.e.: no need to be directly
>     connected) and grab the whole network topology that will be updated
>     using standard routing protocol mechanisms (i.e.: routing updates)
>     and that would allow the operator to control (through policies and
>     filters) what to distribute and to which server.
>
>     Benefits: single (or dual at most for redundancy) connection for
>     the ALTO server (rather than having a direct adjacency with each
>     ABR) and, from the operator perspective, single point of
>     distribution of network topology (easier to apply policies and
>     control what you deliver). This is what BGP-LS is about.
>
> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
> link-state and, more generically, any type of topology information.
> The draft specifies NLRI and attributes that map whatever you can
> find in a link-state database.
>
> We currently have draft-gredler-idr-ls-distribution in the process
> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting
> good support). We also have 3 implementations of BGP-LS.
>
> Deployment-wise: BGP-LS is not yet deployed, however, we already have
> deployments (I know at least two) where an ALTO server retrieves IP
> prefix information from remote BGP RRs (for ipv4). The same scheme
> will be used once BGP-LS will be deployed (so to say that it is not
> something that we invented after a couple of beers but corresponds to
> requirements for delivering network services to upper layers while
> still controlling efficiently what you distribute, to whom and in
> which form (note that, often, beers are anyway part of the process).
>
> More information here:
> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
> http://tools.ietf.org/html/draft-ietf-alto-protocol-12
>
> Hope this helps.
>
> s.
>
>
>
> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
>> Tom,
>>
>>> I agree that one of the top work items for this effort should be a
>>> standardized topology function, and one that is accessible via a
>>> non-routing protocol.
>> So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS.
>>
>> However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation.
>>
>> The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;)
>>
>> R.
>>
>>> 	I agree that one of the top work items for this effort should be a
>>> standardized topology function, and one that is accessible via a
>>> non-routing protocol.  While not exactly "low hanging fruit", it is
>>> something that (to me) is a clear work item with clear goals that should
>>> be tackled straight away.
>>>
>>> 	--Tom
>>>
>>>
>>>
>>> On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>>>
>>>> So after seeing part of Alia's talk this morning (I had to leave in the
>>>> middle unfortunately), I'd like to make a couple suggestions. There were
>>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>>> think to make tangible progress, the work needs to be focussed on a small
>>>> subset that would be of immediate interest and usability.
>>>>
>>>> There are a couple areas that suggest themselves, but one that would be
>>>> useful in work that I've been involved in is a standardized format for
>>>> network topology representation and a protocol for exchanging it. The
>>>> Onix OpenFlow controller has a network information base with a
>>>> specialized format for network topology, and every OpenFlow controller
>>>> requires this. Having a standardized way to represent it might foster a
>>>> common topology database package. Another application is network
>>>> management. Every network management system needs some kind of topology
>>>> representation. Finally, though I am not an expert in PCE construction,
>>>> it would seem to me that a PCE would need some kind of topology
>>>> representation in order to perform path calculations. Having a way,for
>>>> example, for the OpenFlow controller and the PCE to exchange topology
>>>> information would be really useful.  I would say to start with physical
>>>> topology because that is fundamental, but make the format flexible enough
>>>> to support
>>>> virtual topology representation.
>>>>
>>>> 			jak
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: stefano previdi <[email-masked]>
Date: Fri, 3 Aug 2012 08:54:16 +0200
To: [email-masked]
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, [email-masked]
Subject: [irs-discuss]  About ALTO Vs. BGP-LS

All, 

as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few 
things:

ALTO has been designed in order to deliver to applications (through 
http/json):

1. two maps representing the network topology in an abstracted view 
   (or set of views through multiple maps). The map does not include 
   the details of a link-state database and therefore have little use 
   for any element that would need to retrieve from the network the 
   detailed/complete network layer topology, for example: link 
   addresses or link BW resources, etc. IOW: ALTO maps do not have 
   the granularity of a link-state database and ALTO protocol is not 
   designed to deliver such details.

and/or

2. Ranking services where a client sends a bunch of IP addresses in 
   a message and the ALTO server replies by ranking these addresses 
   based on their topological/network distance (or whatever criteria 
   the ALTO server has been configured for). This is called: Endpoint 
   Cost Service.

When using ALTO maps, and the ALTO protocol being http/pull based, 
there's no such concept of unsolicited routing updates. An ALTO 
client is typically a browser that will pull the maps from an ALTO 
server using http. The ALTO server will make no effort to ensure the 
client has the latest view of the topology (i.e.: It's the role of the 
client to poll for new maps time to time).

Now, in order for an ALTO server to deliver Maps or Ranking services, 
it needs to build some form of topology and in order to achieve this, 
it needs somehow to be fed by either the operator (configuration) or 
to receive dynamically topology information from the network (e.g.: 
ISIS/OSPF/BGP).

Here we had two options:
1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies 
   to ABRs or L1L2 routers in each area so to retrieve the LSDB from 
   each area. In practice I know no SP willing/accepting to open their 
   IGP to an ALTO server. Also, IGP requires direct connectivity 
   (adjacency) so from an operation point of view is complex and not 
   desired.
2. Use a database distribution protocol running on top of a reliable 
   transport layer that would allow an ALTO server to connect to a 
   _single_ and _remote_ Route Reflector (i.e.: no need to be directly 
   connected) and grab the whole network topology that will be updated 
   using standard routing protocol mechanisms (i.e.: routing updates)
   and that would allow the operator to control (through policies and 
   filters) what to distribute and to which server.

   Benefits: single (or dual at most for redundancy) connection for 
   the ALTO server (rather than having a direct adjacency with each 
   ABR) and, from the operator perspective, single point of 
   distribution of network topology (easier to apply policies and 
   control what you deliver). This is what BGP-LS is about. 

BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey 
link-state and, more generically, any type of topology information. 
The draft specifies NLRI and attributes that map whatever you can 
find in a link-state database.

We currently have draft-gredler-idr-ls-distribution in the process 
(hopefully) to be adopted as WG item in IDR WG (so far we 're getting 
good support). We also have 3 implementations of BGP-LS.

Deployment-wise: BGP-LS is not yet deployed, however, we already have 
deployments (I know at least two) where an ALTO server retrieves IP 
prefix information from remote BGP RRs (for ipv4). The same scheme 
will be used once BGP-LS will be deployed (so to say that it is not 
something that we invented after a couple of beers but corresponds to 
requirements for delivering network services to upper layers while 
still controlling efficiently what you distribute, to whom and in 
which form (note that, often, beers are anyway part of the process).

More information here:
http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
http://tools.ietf.org/html/draft-ietf-alto-protocol-12

Hope this helps.

s.

On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
> Tom,
> 
> > I agree that one of the top work items for this effort should be a
> > standardized topology function, and one that is accessible via a
> > non-routing protocol.
> 
> So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS.
> 
> However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation.
> 
> The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;)
> 
> R.
> 
>> 
>> 	I agree that one of the top work items for this effort should be a
>> standardized topology function, and one that is accessible via a
>> non-routing protocol.  While not exactly "low hanging fruit", it is
>> something that (to me) is a clear work item with clear goals that should
>> be tackled straight away.
>> 
>> 	--Tom
>> 
>> 
>> 
>> On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>> 
>>> So after seeing part of Alia's talk this morning (I had to leave in the
>>> middle unfortunately), I'd like to make a couple suggestions. There were
>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>> think to make tangible progress, the work needs to be focussed on a small
>>> subset that would be of immediate interest and usability.
>>> 
>>> There are a couple areas that suggest themselves, but one that would be
>>> useful in work that I've been involved in is a standardized format for
>>> network topology representation and a protocol for exchanging it. The
>>> Onix OpenFlow controller has a network information base with a
>>> specialized format for network topology, and every OpenFlow controller
>>> requires this. Having a standardized way to represent it might foster a
>>> common topology database package. Another application is network
>>> management. Every network management system needs some kind of topology
>>> representation. Finally, though I am not an expert in PCE construction,
>>> it would seem to me that a PCE would need some kind of topology
>>> representation in order to perform path calculations. Having a way,for
>>> example, for the OpenFlow controller and the PCE to exchange topology
>>> information would be really useful.  I would say to start with physical
>>> topology because that is fundamental, but make the format flexible enough
>>> to support
>>> virtual topology representation.
>>> 
>>> 			jak
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
>> 
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

From: "Jan Medved (jmedved)" <[email-masked]>
To: Thomas Nadeau <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 3 Aug 2012 05:33:49 +0000
Accept-Language: en-US
Cc: James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Tom,

On 8/2/12 4:42 PM, "Thomas Nadeau" <[email-masked]> wrote:

>
>
>On 8/2/12 4:29 PM, "Robert Raszuk" <[email-masked]> wrote:
>
>>Tom,
>>
>> > I agree that one of the top work items for this effort should be a
>> > standardized topology function, and one that is accessible via a
>> > non-routing protocol.
>>
>>So if the requirement is to have topology export via non-routing
>>protocol then I think we should seriously revisit or repackage the
>>draft-gredler-idr-ls-distribution-01 which works for for both OSPF and
>>ISIS.
>
>	Cool.
>
>
>>However before that let's really understand the requirement why it must
>>be exported via non-routing protocol .... Keep in mind that just to
>>parse BGP UPDATE messages and retrieve interesting pieces out it it
>>requires very little code rather then full BGP implementation.

Agreed.

>
>	That seemed to be one of the agreements that came out of the session
>today.

Can you give more background?

I don't think it's as straightforward. BGP-LS implements a network-wide
model (data schema), while the scope of IRS is a single node (IMO as it
should be). A node's local IGP and BGP databases do not provide the view
of the entire network topology. To get the whole topology, multiple
routers need to be queried, and the topology needs to be 'stitched'
together. This can either be done in an external node (an ALTO Server, for
example), or in a router.

If the 'stitching' is done in an external server, would it mean that the
scope of IRS is extended to entities other than routers?

If the 'stitching' is done at a router, then the router would have to
collect the topology data from other routers - using BGP-LS, for example
;-) The topology export would then basically have to provide access to the
BGP-LS database through some adaptation function. I wonder what's the gain
in this case...
 
>
>	--Tom
>

Thanks,
Jan

>
>>

From: "Jan Medved (jmedved)" <[email-masked]>
To: Susan Hares <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Sue,

On 8/2/12 6:15 PM, "Susan Hares" <[email-masked]> wrote:

>James:
>
>BGP and ISIS may have overkill - or it may be just right.  Realize - this
>information does not come for free.

Agreed. 

It costs to extract the topology information from the router, and it costs
to process it a the client. A routing protocol is a good low cost
interface to get topology data out of a router, since routing is one of
the things that routers are optimized for.

Now, if a client does not want to listen to BGP Updates (which is not that
difficult to implement, as Robert pointed out), we can have an
intermediary, such an ALTO Server, which will receive routing protocol
updates and provide the topology to clients in an easier-to-digest format.

>
>You are running BGP sessions across the network passing this information.
>All of the routers must be configured and instrumented separately from
>the regular BGP. ISIS uploaded into these BGP sessions and distributed.

Not necessarily. In a single-area IGP, a single BGP-LS speaker listening
to IGP updates can retrieve the IGP topology for the whole network. Other
BGP Speakers in the network do not need to be BGP-LS enabled at all.

If we want to retrieve a complete topology of a multi-area IGP network,
there must be an IGP listener in each IGP area. If a client wants to use
BGP-LS to retrieve the IGP topology from the network, it can set up a
BGP-LS session to each of the IGP listeners (in each area). Alternatively,
we can use a Route Reflector to collect the topology data from all BGP-LS
Speakers; then, the client only needs to establish a single session to the
Route Reflector. Also, the Route Reflector can service multiple clients.
Note that in this case there too is only a small set of routers than need
to be BGP-LS enabled.

Basically, we leverage existing BGP mechanisms to collect the topology
data from the entire network. We can leverage an existing Route Reflector,
or we can dedicate a Route Reflector just for BGP-LS. Talking to multiple
operators, they prefer the latter option.

>
>Please ask the authors about the details of their implementations.

Sure, if more details are required, we'll be glad to discuss :-)

>
>Sue 
>
Thanks,
Jan

>
>-----Original Message-----
>From: James Kempf [mailto:[email-masked]]
>Sent: Thursday, August 02, 2012 4:53 PM
>To: Susan Hares; [email-masked]
>Cc: [email-masked]
>Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>
>I'll have to take a look at draft-grendler, I am not familiar with it.
>
>The particular use cases I'm interested in are NMS and OpenFlow
>controller type applications where some centralized entity wants
>information on the topology for managing the elements in a way that
>allows policies to be expressed over the network as a whole and
>translated into specific element management polices by the controller/NMS
>system. The topology data base must be populated somehow, obviously, but
>I assume that would be part of the work (perhaps draft-grendler describes
>this). The physical topology won't be exported outside an operator's
>domain since managing the physical infrastructure is under the purview of
>the operator. If the topology database supports expressing virtual
>topologies (which I believe it should) the operator could expose virtual
>topologies to the customers of the virtual networks, and allow them the
>ability to manage their virtual slices.
>
>Make sense?
>
>			jak  
>
>> -----Original Message-----
>> From: Susan Hares [mailto:[email-masked]]
>> Sent: Thursday, August 02, 2012 4:30 PM
>> To: [email-masked]; James Kempf
>> Cc: [email-masked]
>> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
>> 
>> James:
>> 
>> This is the full detailed routes.  However, will every ISP
>> share it's ISIS topology.
>> 
>> Sue 
>> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Robert Raszuk
>> Sent: Thursday, August 02, 2012 4:21 PM
>> To: James Kempf
>> Cc: [email-masked]
>> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
>> 
>> Hi James,
>> 
>> On the topic of topology export it is my understanding that
>> we do already have a solution which in fact even authors of
>> IRS framework support and are putting under their umbrella.
>> 
>> That is: 
>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01
>> 
>> The draft as standards track document defines the topology
>> export standard in form of link and node NLRIs with bunch of TLVs.
>> 
>> So the key aspect would be to see what is missing and if
>> something is missing in the space of topology export to
>> evaluate if this solution by principle can be extended to
>> accommodate it.
>> 
>> Best,
>> R.
>> 
>> 
>> > So after seeing part of Alia's talk this morning (I had to leave in
>> > the middle unfortunately), I'd like to make a couple suggestions.
>> > There were a lot of ideas presented in the talk, enough for
>> an entire 
>> > IETF Area. I think to make tangible progress, the work needs to be
>> > focussed on a small subset that would be of immediate interest and
>> > usability.
>> >
>> > There are a couple areas that suggest themselves, but one
>> that would 
>> > be useful in work that I've been involved in is a
>> standardized format
>> > for network topology representation and a protocol for
>> exchanging it.
>> > The Onix OpenFlow controller has a network information base with a
>> > specialized format for network topology, and every OpenFlow
>> controller 
>> > requires this. Having a standardized way to represent it
>> might foster 
>> > a common topology database package. Another application is network
>> > management. Every network management system needs some kind of
>> > topology representation. Finally, though I am not an expert in PCE
>> > construction, it would seem to me that a PCE would need
>> some kind of 
>> > topology representation in order to perform path
>> calculations. Having
>> > a way,for example, for the OpenFlow controller and the PCE
>> to exchange 
>> > topology information would be really useful.
>> > I would say to start with physical topology because that is
>> > fundamental, but make the format flexible enough to support virtual
>> > topology representation.
>> >
>> > jak _______________________________________________ irs-discuss
>> > mailing list [email-masked]
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>> >
>> >
>> 
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 3 Aug 2012 01:15:53 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

James:

BGP and ISIS may have overkill - or it may be just right.  Realize - this information does not come for free. 

You are running BGP sessions across the network passing this information. All of the routers must be configured and instrumented separately from the regular BGP. ISIS uploaded into these BGP sessions and distributed.  

Please ask the authors about the details of their implementations. 

Sue 

-----Original Message-----
From: James Kempf [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 4:53 PM
To: Susan Hares; [email-masked]
Cc: [email-masked]
Subject: RE: [irs-discuss] Suggestions for IRS Way Forward

I'll have to take a look at draft-grendler, I am not familiar with it.

The particular use cases I'm interested in are NMS and OpenFlow controller type applications where some centralized entity wants information on the topology for managing the elements in a way that allows policies to be expressed over the network as a whole and translated into specific element management polices by the controller/NMS system. The topology data base must be populated somehow, obviously, but I assume that would be part of the work (perhaps draft-grendler describes this). The physical topology won't be exported outside an operator's domain since managing the physical infrastructure is under the purview of the operator. If the topology database supports expressing virtual topologies (which I believe it should) the operator could expose virtual topologies to the customers of the virtual networks, and allow them the ability to manage their virtual slices.

Make sense?

			jak  

> -----Original Message-----
> From: Susan Hares [mailto:[email-masked]] 
> Sent: Thursday, August 02, 2012 4:30 PM
> To: [email-masked]; James Kempf
> Cc: [email-masked]
> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
> 
> James:
> 
> This is the full detailed routes.  However, will every ISP 
> share it's ISIS topology.
> 
> Sue 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Raszuk
> Sent: Thursday, August 02, 2012 4:21 PM
> To: James Kempf
> Cc: [email-masked]
> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
> 
> Hi James,
> 
> On the topic of topology export it is my understanding that 
> we do already have a solution which in fact even authors of 
> IRS framework support and are putting under their umbrella.
> 
> That is: 
> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01
> 
> The draft as standards track document defines the topology 
> export standard in form of link and node NLRIs with bunch of TLVs.
> 
> So the key aspect would be to see what is missing and if 
> something is missing in the space of topology export to 
> evaluate if this solution by principle can be extended to 
> accommodate it.
> 
> Best,
> R.
> 
> 
> > So after seeing part of Alia's talk this morning (I had to leave in 
> > the middle unfortunately), I'd like to make a couple suggestions.
> > There were a lot of ideas presented in the talk, enough for 
> an entire 
> > IETF Area. I think to make tangible progress, the work needs to be 
> > focussed on a small subset that would be of immediate interest and 
> > usability.
> >
> > There are a couple areas that suggest themselves, but one 
> that would 
> > be useful in work that I've been involved in is a 
> standardized format 
> > for network topology representation and a protocol for 
> exchanging it.
> > The Onix OpenFlow controller has a network information base with a 
> > specialized format for network topology, and every OpenFlow 
> controller 
> > requires this. Having a standardized way to represent it 
> might foster 
> > a common topology database package. Another application is network 
> > management. Every network management system needs some kind of 
> > topology representation. Finally, though I am not an expert in PCE 
> > construction, it would seem to me that a PCE would need 
> some kind of 
> > topology representation in order to perform path 
> calculations. Having 
> > a way,for example, for the OpenFlow controller and the PCE 
> to exchange 
> > topology information would be really useful.
> > I would say to start with physical topology because that is 
> > fundamental, but make the format flexible enough to support virtual 
> > topology representation.
> >
> > jak _______________________________________________ irs-discuss 
> > mailing list [email-masked] 
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> >
> >
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

Date: Fri, 03 Aug 2012 02:02:20 +0200
From: Robert Raszuk <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [irs-discuss] An idea ... MTR + IRS
Reply-To: [email-masked]

Hi,

This morning Scott mentioned that he would like to use IRS to shut down 
all protocols and just be able to write to RIB. Now James said that he 
would like to get a network topology as "every OpenFlow controller 
requires this"

Both connected together resulted in an idea of using 
multi-topology-routing where your base topology discovers physical link 
connectivity graph while other topologies could be programmed by 
external entities example: OF controllers or any other external to 
routers network intelligence oracles to deliver actual services ?

Would that be in scope of IRS effort ? If so what would be the proposed 
"write to RIB" set of protocols ? Would you support OF 1.3 even if one 
would be happy to lock such topologies only to software/programmable 
switching paths ?

Best rgs,
R.

From: James Kempf <[email-masked]>
To: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 19:53:17 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

I'll have to take a look at draft-grendler, I am not familiar with it.

The particular use cases I'm interested in are NMS and OpenFlow controller type applications where some centralized entity wants information on the topology for managing the elements in a way that allows policies to be expressed over the network as a whole and translated into specific element management polices by the controller/NMS system. The topology data base must be populated somehow, obviously, but I assume that would be part of the work (perhaps draft-grendler describes this). The physical topology won't be exported outside an operator's domain since managing the physical infrastructure is under the purview of the operator. If the topology database supports expressing virtual topologies (which I believe it should) the operator could expose virtual topologies to the customers of the virtual networks, and allow them the ability to manage their virtual slices.

Make sense?

			jak  

> -----Original Message-----
> From: Susan Hares [mailto:[email-masked]] 
> Sent: Thursday, August 02, 2012 4:30 PM
> To: [email-masked]; James Kempf
> Cc: [email-masked]
> Subject: RE: [irs-discuss] Suggestions for IRS Way Forward
> 
> James:
> 
> This is the full detailed routes.  However, will every ISP 
> share it's ISIS topology.
> 
> Sue 
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Robert Raszuk
> Sent: Thursday, August 02, 2012 4:21 PM
> To: James Kempf
> Cc: [email-masked]
> Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
> 
> Hi James,
> 
> On the topic of topology export it is my understanding that 
> we do already have a solution which in fact even authors of 
> IRS framework support and are putting under their umbrella.
> 
> That is: 
> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01
> 
> The draft as standards track document defines the topology 
> export standard in form of link and node NLRIs with bunch of TLVs.
> 
> So the key aspect would be to see what is missing and if 
> something is missing in the space of topology export to 
> evaluate if this solution by principle can be extended to 
> accommodate it.
> 
> Best,
> R.
> 
> 
> > So after seeing part of Alia's talk this morning (I had to leave in 
> > the middle unfortunately), I'd like to make a couple suggestions.
> > There were a lot of ideas presented in the talk, enough for 
> an entire 
> > IETF Area. I think to make tangible progress, the work needs to be 
> > focussed on a small subset that would be of immediate interest and 
> > usability.
> >
> > There are a couple areas that suggest themselves, but one 
> that would 
> > be useful in work that I've been involved in is a 
> standardized format 
> > for network topology representation and a protocol for 
> exchanging it.
> > The Onix OpenFlow controller has a network information base with a 
> > specialized format for network topology, and every OpenFlow 
> controller 
> > requires this. Having a standardized way to represent it 
> might foster 
> > a common topology database package. Another application is network 
> > management. Every network management system needs some kind of 
> > topology representation. Finally, though I am not an expert in PCE 
> > construction, it would seem to me that a PCE would need 
> some kind of 
> > topology representation in order to perform path 
> calculations. Having 
> > a way,for example, for the OpenFlow controller and the PCE 
> to exchange 
> > topology information would be really useful.
> > I would say to start with physical topology because that is 
> > fundamental, but make the format flexible enough to support virtual 
> > topology representation.
> >
> > jak _______________________________________________ irs-discuss 
> > mailing list [email-masked] 
> > https://www.ietf.org/mailman/listinfo/irs-discuss
> >
> >
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

From: Thomas Nadeau <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 19:42:44 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

On 8/2/12 4:29 PM, "Robert Raszuk" <[email-masked]> wrote:

>Tom,
>
> > I agree that one of the top work items for this effort should be a
> > standardized topology function, and one that is accessible via a
> > non-routing protocol.
>
>So if the requirement is to have topology export via non-routing
>protocol then I think we should seriously revisit or repackage the
>draft-gredler-idr-ls-distribution-01 which works for for both OSPF and
>ISIS.

	Cool.

>However before that let's really understand the requirement why it must
>be exported via non-routing protocol .... Keep in mind that just to
>parse BGP UPDATE messages and retrieve interesting pieces out it it
>requires very little code rather then full BGP implementation.

	That seemed to be one of the agreements that came out of the session
today.

	--Tom

>
>The particular feature I like about draft-gredler-idr-ls-distribution-01
>is that it is read-only ;)
>
>R.
>
>>
>> 	I agree that one of the top work items for this effort should be a
>> standardized topology function, and one that is accessible via a
>> non-routing protocol.  While not exactly "low hanging fruit", it is
>> something that (to me) is a clear work item with clear goals that should
>> be tackled straight away.
>>
>> 	--Tom
>>
>>
>>
>> On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>>
>>> So after seeing part of Alia's talk this morning (I had to leave in the
>>> middle unfortunately), I'd like to make a couple suggestions. There
>>>were
>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>> think to make tangible progress, the work needs to be focussed on a
>>>small
>>> subset that would be of immediate interest and usability.
>>>
>>> There are a couple areas that suggest themselves, but one that would be
>>> useful in work that I've been involved in is a standardized format for
>>> network topology representation and a protocol for exchanging it. The
>>> Onix OpenFlow controller has a network information base with a
>>> specialized format for network topology, and every OpenFlow controller
>>> requires this. Having a standardized way to represent it might foster a
>>> common topology database package. Another application is network
>>> management. Every network management system needs some kind of topology
>>> representation. Finally, though I am not an expert in PCE construction,
>>> it would seem to me that a PCE would need some kind of topology
>>> representation in order to perform path calculations. Having a way,for
>>> example, for the OpenFlow controller and the PCE to exchange topology
>>> information would be really useful.  I would say to start with physical
>>> topology because that is fundamental, but make the format flexible
>>>enough
>>> to support
>>> virtual topology representation.
>>>
>>> 			jak
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>

From: Susan Hares <[email-masked]>
To: Ping Pan <[email-masked]>, Pedro Roque Marques <[email-masked]>
Date: Thu, 2 Aug 2012 23:39:01 +0000
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] if-map example

--_000_728F9B956B2C48439CA9294B1723B14623755EAFdfweml509mbschi_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQo
--_000_728F9B956B2C48439CA9294B1723B14623755EAFdfweml509mbschi_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_728F9B956B2C48439CA9294B1723B14623755EAFdfweml509mbschi_--

From: Susan Hares <[email-masked]>
To: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 23:36:57 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Tom:

Knowing authors of these drafts, this is true. They believe there is more to do. They proposed initial work and provide running code to test the ideas. 

Love to hear about where you think the holes are in each of these protocols. 

Sue 

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Thursday, August 02, 2012 4:28 PM
To: Susan Hares; James Kempf; [email-masked]
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

On 8/2/12 4:21 PM, "Susan Hares" <[email-masked]> wrote:

>Tom:
>
>So, is ALTO, PCE, Yang modules with topology in scope.

	I think those are very good and important components yes.

>Are you stating that we do not re-inventing the ALTO functions topology
>(see previous note)?

	I'd definitely prefer to not reinvent those functions unless there are
good reasons to do so.
However, as Alia explained during the meeting, they are incomplete.

	--Tom

> 
>
>Sue 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Thomas Nadeau
>Sent: Thursday, August 02, 2012 3:32 PM
>To: James Kempf; [email-masked]
>Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
>
>
>	I agree that one of the top work items for this effort should be a
>standardized topology function, and one that is accessible via a
>non-routing protocol.  While not exactly "low hanging fruit", it is
>something that (to me) is a clear work item with clear goals that should
>be tackled straight away.
>
>	--Tom
>
>
>
>On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>
>>So after seeing part of Alia's talk this morning (I had to leave in the
>>middle unfortunately), I'd like to make a couple suggestions. There were
>>a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>think to make tangible progress, the work needs to be focussed on a small
>>subset that would be of immediate interest and usability.
>>
>>There are a couple areas that suggest themselves, but one that would be
>>useful in work that I've been involved in is a standardized format for
>>network topology representation and a protocol for exchanging it. The
>>Onix OpenFlow controller has a network information base with a
>>specialized format for network topology, and every OpenFlow controller
>>requires this. Having a standardized way to represent it might foster a
>>common topology database package. Another application is network
>>management. Every network management system needs some kind of topology
>>representation. Finally, though I am not an expert in PCE construction,
>>it would seem to me that a PCE would need some kind of topology
>>representation in order to perform path calculations. Having a way,for
>>example, for the OpenFlow controller and the PCE to exchange topology
>>information would be really useful.  I would say to start with physical
>>topology because that is fundamental, but make the format flexible enough
>>to support 
>> virtual topology representation.
>>
>>			jak
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: "[email-masked]" <[email-masked]>, James Kempf <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

James:

This is the full detailed routes.  However, will every ISP share it's ISIS topology.

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert Raszuk
Sent: Thursday, August 02, 2012 4:21 PM
To: James Kempf
Cc: [email-masked]
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Hi James,

On the topic of topology export it is my understanding that we do 
already have a solution which in fact even authors of IRS framework 
support and are putting under their umbrella.

That is: http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01

The draft as standards track document defines the topology export 
standard in form of link and node NLRIs with bunch of TLVs.

So the key aspect would be to see what is missing and if something is 
missing in the space of topology export to evaluate if this solution by 
principle can be extended to accommodate it.

Best,
R.

> So after seeing part of Alia's talk this morning (I had to leave in
> the middle unfortunately), I'd like to make a couple suggestions.
> There were a lot of ideas presented in the talk, enough for an entire
> IETF Area. I think to make tangible progress, the work needs to be
> focussed on a small subset that would be of immediate interest and
> usability.
>
> There are a couple areas that suggest themselves, but one that would
> be useful in work that I've been involved in is a standardized format
> for network topology representation and a protocol for exchanging it.
> The Onix OpenFlow controller has a network information base with a
> specialized format for network topology, and every OpenFlow
> controller requires this. Having a standardized way to represent it
> might foster a common topology database package. Another application
> is network management. Every network management system needs some
> kind of topology representation. Finally, though I am not an expert
> in PCE construction, it would seem to me that a PCE would need some
> kind of topology representation in order to perform path
> calculations. Having a way,for example, for the OpenFlow controller
> and the PCE to exchange topology information would be really useful.
> I would say to start with physical topology because that is
> fundamental, but make the format flexible enough to support virtual
> topology representation.
>
> jak _______________________________________________ irs-discuss
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

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

Date: Fri, 03 Aug 2012 01:29:57 +0200
From: Robert Raszuk <[email-masked]>
To: Thomas Nadeau <[email-masked]>
Cc: James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
Reply-To: [email-masked]

Tom,

 > I agree that one of the top work items for this effort should be a
 > standardized topology function, and one that is accessible via a
 > non-routing protocol.

So if the requirement is to have topology export via non-routing 
protocol then I think we should seriously revisit or repackage the 
draft-gredler-idr-ls-distribution-01 which works for for both OSPF and 
ISIS.

However before that let's really understand the requirement why it must 
be exported via non-routing protocol .... Keep in mind that just to 
parse BGP UPDATE messages and retrieve interesting pieces out it it 
requires very little code rather then full BGP implementation.

The particular feature I like about draft-gredler-idr-ls-distribution-01 
is that it is read-only ;)

R.

>
> 	I agree that one of the top work items for this effort should be a
> standardized topology function, and one that is accessible via a
> non-routing protocol.  While not exactly "low hanging fruit", it is
> something that (to me) is a clear work item with clear goals that should
> be tackled straight away.
>
> 	--Tom
>
>
>
> On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>
>> So after seeing part of Alia's talk this morning (I had to leave in the
>> middle unfortunately), I'd like to make a couple suggestions. There were
>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>> think to make tangible progress, the work needs to be focussed on a small
>> subset that would be of immediate interest and usability.
>>
>> There are a couple areas that suggest themselves, but one that would be
>> useful in work that I've been involved in is a standardized format for
>> network topology representation and a protocol for exchanging it. The
>> Onix OpenFlow controller has a network information base with a
>> specialized format for network topology, and every OpenFlow controller
>> requires this. Having a standardized way to represent it might foster a
>> common topology database package. Another application is network
>> management. Every network management system needs some kind of topology
>> representation. Finally, though I am not an expert in PCE construction,
>> it would seem to me that a PCE would need some kind of topology
>> representation in order to perform path calculations. Having a way,for
>> example, for the OpenFlow controller and the PCE to exchange topology
>> information would be really useful.  I would say to start with physical
>> topology because that is fundamental, but make the format flexible enough
>> to support
>> virtual topology representation.
>>
>> 			jak
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

Date: Thu, 2 Aug 2012 19:29:37 -0400
From: Alia Atlas <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] if-map example

Pedro,

Thanks for sending out the references.  I'll definitely take a look.

Alia

On Thu, Aug 2, 2012 at 2:07 PM, Pedro Roque Marques
<[email-masked]> wrote:
> As i pointed out in the RT area meeting, i believe that IF-MAP is a successful example of what can be achieved by network-wide schemas (vs network element schemas).
>
> The current spec is at:
> http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf
>
> if-map.org has lots of material on the use cases.
>
> As per my comment on the mic, i'd like to encourage the IRS to focus on data schemas that describe network state.
>
> thank you,
>   Pedro.
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Thomas Nadeau <[email-masked]>
To: Susan Hares <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 19:28:17 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

On 8/2/12 4:21 PM, "Susan Hares" <[email-masked]> wrote:

>Tom:
>
>So, is ALTO, PCE, Yang modules with topology in scope.

	I think those are very good and important components yes.

>Are you stating that we do not re-inventing the ALTO functions topology
>(see previous note)?

	I'd definitely prefer to not reinvent those functions unless there are
good reasons to do so.
However, as Alia explained during the meeting, they are incomplete.

	--Tom

> 
>
>Sue 
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>On Behalf Of Thomas Nadeau
>Sent: Thursday, August 02, 2012 3:32 PM
>To: James Kempf; [email-masked]
>Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
>
>
>	I agree that one of the top work items for this effort should be a
>standardized topology function, and one that is accessible via a
>non-routing protocol.  While not exactly "low hanging fruit", it is
>something that (to me) is a clear work item with clear goals that should
>be tackled straight away.
>
>	--Tom
>
>
>
>On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>
>>So after seeing part of Alia's talk this morning (I had to leave in the
>>middle unfortunately), I'd like to make a couple suggestions. There were
>>a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>think to make tangible progress, the work needs to be focussed on a small
>>subset that would be of immediate interest and usability.
>>
>>There are a couple areas that suggest themselves, but one that would be
>>useful in work that I've been involved in is a standardized format for
>>network topology representation and a protocol for exchanging it. The
>>Onix OpenFlow controller has a network information base with a
>>specialized format for network topology, and every OpenFlow controller
>>requires this. Having a standardized way to represent it might foster a
>>common topology database package. Another application is network
>>management. Every network management system needs some kind of topology
>>representation. Finally, though I am not an expert in PCE construction,
>>it would seem to me that a PCE would need some kind of topology
>>representation in order to perform path calculations. Having a way,for
>>example, for the OpenFlow controller and the PCE to exchange topology
>>information would be really useful.  I would say to start with physical
>>topology because that is fundamental, but make the format flexible enough
>>to support 
>> virtual topology representation.
>>
>>			jak
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 23:22:20 +0000
Accept-Language: en-US, zh-CN
Subject: [irs-discuss] Dave Meyer's reference

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

Dave Meyer - or anyone else

Does anyone a pointer to the work Dave referenced during the IRS meeting?  Or does the note taker have information?

Thanks,

Sue

--_000_728F9B956B2C48439CA9294B1723B14623755E48dfweml509mbschi_
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;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.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">Dave Meyer &#8211; or anyone else <o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Does anyone a pointer to the work Dave referenced during the IRS meeting? &nbsp;Or does the note taker have information?
<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Sue <o:p></o:p></p>
</div>
</body>
</html>

--_000_728F9B956B2C48439CA9294B1723B14623755E48dfweml509mbschi_--

From: Susan Hares <[email-masked]>
To: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Accept-Language: en-US, zh-CN
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

Tom:

So, is ALTO, PCE, Yang modules with topology in scope.

Are you stating that we do not re-inventing the ALTO functions topology (see previous note)? 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Nadeau
Sent: Thursday, August 02, 2012 3:32 PM
To: James Kempf; [email-masked]
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

	I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol.  While not exactly "low hanging fruit", it is
something that (to me) is a clear work item with clear goals that should
be tackled straight away.

	--Tom

On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:

>So after seeing part of Alia's talk this morning (I had to leave in the
>middle unfortunately), I'd like to make a couple suggestions. There were
>a lot of ideas presented in the talk, enough for an entire IETF Area. I
>think to make tangible progress, the work needs to be focussed on a small
>subset that would be of immediate interest and usability.
>
>There are a couple areas that suggest themselves, but one that would be
>useful in work that I've been involved in is a standardized format for
>network topology representation and a protocol for exchanging it. The
>Onix OpenFlow controller has a network information base with a
>specialized format for network topology, and every OpenFlow controller
>requires this. Having a standardized way to represent it might foster a
>common topology database package. Another application is network
>management. Every network management system needs some kind of topology
>representation. Finally, though I am not an expert in PCE construction,
>it would seem to me that a PCE would need some kind of topology
>representation in order to perform path calculations. Having a way,for
>example, for the OpenFlow controller and the PCE to exchange topology
>information would be really useful.  I would say to start with physical
>topology because that is fundamental, but make the format flexible enough
>to support 
> virtual topology representation.
>
>			jak
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

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

Date: Fri, 03 Aug 2012 01:20:47 +0200
From: Robert Raszuk <[email-masked]>
To: James Kempf <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward
Reply-To: [email-masked]

Hi James,

On the topic of topology export it is my understanding that we do 
already have a solution which in fact even authors of IRS framework 
support and are putting under their umbrella.

That is: http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-01

The draft as standards track document defines the topology export 
standard in form of link and node NLRIs with bunch of TLVs.

So the key aspect would be to see what is missing and if something is 
missing in the space of topology export to evaluate if this solution by 
principle can be extended to accommodate it.

Best,
R.

> So after seeing part of Alia's talk this morning (I had to leave in
> the middle unfortunately), I'd like to make a couple suggestions.
> There were a lot of ideas presented in the talk, enough for an entire
> IETF Area. I think to make tangible progress, the work needs to be
> focussed on a small subset that would be of immediate interest and
> usability.
>
> There are a couple areas that suggest themselves, but one that would
> be useful in work that I've been involved in is a standardized format
> for network topology representation and a protocol for exchanging it.
> The Onix OpenFlow controller has a network information base with a
> specialized format for network topology, and every OpenFlow
> controller requires this. Having a standardized way to represent it
> might foster a common topology database package. Another application
> is network management. Every network management system needs some
> kind of topology representation. Finally, though I am not an expert
> in PCE construction, it would seem to me that a PCE would need some
> kind of topology representation in order to perform path
> calculations. Having a way,for example, for the OpenFlow controller
> and the PCE to exchange topology information would be really useful.
> I would say to start with physical topology because that is
> fundamental, but make the format flexible enough to support virtual
> topology representation.
>
> jak _______________________________________________ irs-discuss
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>

From: Susan Hares <[email-masked]>
To: James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 23:15:55 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

James:

How would your network topology representation differ from the ALTO-EXT document - such as 

http://tools.ietf.org/pdf/draft-lee-alto-app-net-info-exchange-00.pdf

I'm sure there are many other topology set of information. 

There is the just dumping isis into BGP. 

draft-gredler-idr-ls-distribution-02

And the reported ONIX OpenFlow Controller (see below) 

Or the PCE domain sequence
http://tools.ietf.org/pdf/draft-ietf-pce-pcep-domain-sequence-01.pdf

What do you want for topologies - or do you want a choice? 

What exactly do you mean by topologies? And what's the use case? 

Sue 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of James Kempf
Sent: Thursday, August 02, 2012 3:25 PM
To: [email-masked]
Subject: [irs-discuss] Suggestions for IRS Way Forward

So after seeing part of Alia's talk this morning (I had to leave in the middle unfortunately), I'd like to make a couple suggestions. There were a lot of ideas presented in the talk, enough for an entire IETF Area. I think to make tangible progress, the work needs to be focussed on a small subset that would be of immediate interest and usability. 

There are a couple areas that suggest themselves, but one that would be useful in work that I've been involved in is a standardized format for network topology representation and a protocol for exchanging it. The Onix OpenFlow controller has a network information base with a specialized format for network topology, and every OpenFlow controller requires this. Having a standardized way to represent it might foster a common topology database package. Another application is network management. Every network management system needs some kind of topology representation. Finally, though I am not an expert in PCE construction, it would seem to me that a PCE would need some kind of topology representation in order to perform path calculations. Having a way,for example, for the OpenFlow controller and the PCE to exchange topology information would be really useful.  I would say to start with physical topology because that is fundamental, but make the format flexible enough to support 
 virtual topology representation.

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

From: Ping Pan <[email-masked]>
Date: Thu, 2 Aug 2012 15:35:19 -0700
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] if-map example

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

And this can be extended to apply more than L3VPN...

On Thu, Aug 2, 2012 at 3:18 PM, Pedro Roque Marques <
[email-masked]> wrote:

> As an additional example, the following document describes a schema that
> can be used to provision a VPN (which is implemented by many PEs as
> individual VRFs).
> http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema
>
> The document is still in its early stages.
>
> The problems that can be solved by such a schema is to be able to, for
> instance:
> 1) Query the MAP database for all PEs where a specific VPN is present.
> 2) Ensure that the VRFs associated with a specific VPN consistently
> implement the same policy.
>
> These are both examples of functionality that spans the network rather
> than be localized to a specific router/switch/appliance.
>
>
> On Aug 2, 2012, at 2:32 PM, Ping Pan wrote:
>
> After playing around with a bunch of other schemes, this indeed is one of
> the better ones to use as the base.
>
> Ping
>
> On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques <
> [email-masked]> wrote:
>
>> As i pointed out in the RT area meeting, i believe that IF-MAP is a
>> successful example of what can be achieved by network-wide schemas (vs
>> network element schemas).
>>
>> The current spec is at:
>>
>> http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf
>>
>> if-map.org has lots of material on the use cases.
>>
>> As per my comment on the mic, i'd like to encourage the IRS to focus on
>> data schemas that describe network state.
>>
>> thank you,
>>   Pedro.
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>
>
>

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

And this can be extended to apply more than L3VPN...<br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 3:18 PM, Pedro Roque Marques <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"><div style="word-wrap:break-word"><div>As an additional example, the following document describes a schema that can be used to provision a VPN (which is implemented by many PEs as individual VRFs).</div>

<a href="http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema" target="_blank">http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema</a><div><br></div><div>The document is still in its early stages.</div><div>
<br>
</div><div>The problems that can be solved by such a schema is to be able to, for instance:</div><div>1) Query the MAP database for all PEs where a specific VPN is present.</div><div>2) Ensure that the VRFs associated with a specific VPN consistently implement the same policy.</div>

<div><br></div><div>These are both examples of functionality that spans the network rather than be localized to a specific router/switch/appliance.<div><div class="h5"><br><div><br><div><div>On Aug 2, 2012, at 2:32 PM, Ping Pan wrote:</div>

<br><blockquote type="cite">After playing around with a bunch of other schemes, this indeed is one of the better ones to use as the base.<div><br></div><div>Ping<br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques <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">As i pointed out in the RT area meeting, i believe that IF-MAP is a successful example of what can be achieved by network-wide schemas (vs network element schemas).<br>

<br>
The current spec is at:<br>
<a href="http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf" target="_blank">http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf</a><br>

<br>
<a href="http://if-map.org/" target="_blank">if-map.org</a> has lots of material on the use cases.<br>
<br>
As per my comment on the mic, i&#39;d like to encourage the IRS to focus on data schemas that describe network state.<br>
<br>
thank you,<br>
Â  Pedro.<br>
_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]" target="_blank">[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>
</blockquote></div><br></div>
</blockquote></div><br></div></div></div></div></div></blockquote></div><br>

--20cf30223d5d1eede204c65009d3--

From: Thomas Nadeau <[email-masked]>
To: James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 18:31:39 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

	I agree that one of the top work items for this effort should be a
standardized topology function, and one that is accessible via a
non-routing protocol.  While not exactly "low hanging fruit", it is
something that (to me) is a clear work item with clear goals that should
be tackled straight away.

	--Tom

On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:

>So after seeing part of Alia's talk this morning (I had to leave in the
>middle unfortunately), I'd like to make a couple suggestions. There were
>a lot of ideas presented in the talk, enough for an entire IETF Area. I
>think to make tangible progress, the work needs to be focussed on a small
>subset that would be of immediate interest and usability.
>
>There are a couple areas that suggest themselves, but one that would be
>useful in work that I've been involved in is a standardized format for
>network topology representation and a protocol for exchanging it. The
>Onix OpenFlow controller has a network information base with a
>specialized format for network topology, and every OpenFlow controller
>requires this. Having a standardized way to represent it might foster a
>common topology database package. Another application is network
>management. Every network management system needs some kind of topology
>representation. Finally, though I am not an expert in PCE construction,
>it would seem to me that a PCE would need some kind of topology
>representation in order to perform path calculations. Having a way,for
>example, for the OpenFlow controller and the PCE to exchange topology
>information would be really useful.  I would say to start with physical
>topology because that is fundamental, but make the format flexible enough
>to support 
> virtual topology representation.
>
>			jak
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Thu, 2 Aug 2012 18:29:47 -0400
From: Alia Atlas <[email-masked]>
To: James Kempf <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Suggestions for IRS Way Forward

James,

Thanks for the feedback.  I certainly agree that the topology
data-model should be an early focus and deliverable.

At the end of my talk this morning, I did try to describe how to scope
the work so as to keep it within reasonable bounds to make work.

A way of focusing the work, I think, is to discuss and agree on a few
key use-cases that we want to facilitate.

I fully expect that at least one of those use-cases will depend on the
topology data-model.

Alia

On Thu, Aug 2, 2012 at 6:24 PM, James Kempf <[email-masked]> wrote:
> So after seeing part of Alia's talk this morning (I had to leave in the middle unfortunately), I'd like to make a couple suggestions. There were a lot of ideas presented in the talk, enough for an entire IETF Area. I think to make tangible progress, the work needs to be focussed on a small subset that would be of immediate interest and usability.
>
> There are a couple areas that suggest themselves, but one that would be useful in work that I've been involved in is a standardized format for network topology representation and a protocol for exchanging it. The Onix OpenFlow controller has a network information base with a specialized format for network topology, and every OpenFlow controller requires this. Having a standardized way to represent it might foster a common topology database package. Another application is network management. Every network management system needs some kind of topology representation. Finally, though I am not an expert in PCE construction, it would seem to me that a PCE would need some kind of topology representation in order to perform path calculations. Having a way,for example, for the OpenFlow controller and the PCE to exchange topology information would be really useful.  I would say to start with physical topology because that is fundamental, but make the format flexible enough to support
>  virtual topology representation.
>
>                         jak
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: James Kempf <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 18:24:54 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [irs-discuss] Suggestions for IRS Way Forward

So after seeing part of Alia's talk this morning (I had to leave in the middle unfortunately), I'd like to make a couple suggestions. There were a lot of ideas presented in the talk, enough for an entire IETF Area. I think to make tangible progress, the work needs to be focussed on a small subset that would be of immediate interest and usability. 

There are a couple areas that suggest themselves, but one that would be useful in work that I've been involved in is a standardized format for network topology representation and a protocol for exchanging it. The Onix OpenFlow controller has a network information base with a specialized format for network topology, and every OpenFlow controller requires this. Having a standardized way to represent it might foster a common topology database package. Another application is network management. Every network management system needs some kind of topology representation. Finally, though I am not an expert in PCE construction, it would seem to me that a PCE would need some kind of topology representation in order to perform path calculations. Having a way,for example, for the OpenFlow controller and the PCE to exchange topology information would be really useful.  I would say to start with physical topology because that is fundamental, but make the format flexible enough to support virtual topology representation.

			jak

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 2 Aug 2012 15:18:48 -0700
To: Ping Pan <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] if-map example

--Apple-Mail=_CA5C9F41-5E30-475F-99B1-B04343980483
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

As an additional example, the following document describes a schema that can be used to provision a VPN (which is implemented by many PEs as individual VRFs).
http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema

The document is still in its early stages.

The problems that can be solved by such a schema is to be able to, for instance:
1) Query the MAP database for all PEs where a specific VPN is present.
2) Ensure that the VRFs associated with a specific VPN consistently implement the same policy.

These are both examples of functionality that spans the network rather than be localized to a specific router/switch/appliance.

On Aug 2, 2012, at 2:32 PM, Ping Pan wrote:

> After playing around with a bunch of other schemes, this indeed is one of the better ones to use as the base.
> 
> Ping
> 
> On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques <[email-masked]> wrote:
> As i pointed out in the RT area meeting, i believe that IF-MAP is a successful example of what can be achieved by network-wide schemas (vs network element schemas).
> 
> The current spec is at:
> http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf
> 
> if-map.org has lots of material on the use cases.
> 
> As per my comment on the mic, i'd like to encourage the IRS to focus on data schemas that describe network state.
> 
> thank you,
>   Pedro.
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

--Apple-Mail=_CA5C9F41-5E30-475F-99B1-B04343980483
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>As an additional example, the following document describes a schema that can be used to provision a VPN (which is implemented by many PEs as individual VRFs).</div><a href="http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema">http://datatracker.ietf.org/doc/draft-marques-l3vpn-schema</a><div><br></div><div>The document is still in its early stages.</div><div><br></div><div>The problems that can be solved by such a schema is to be able to, for instance:</div><div>1) Query the MAP database for all PEs where a specific VPN is present.</div><div>2) Ensure that the VRFs associated with a specific VPN consistently implement the same policy.</div><div><br></div><div>These are both examples of functionality that spans the network rather than be localized to a specific router/switch/appliance.<br><div><br><div><div>On Aug 2, 2012, at 2:32 PM, Ping Pan wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">After playing around with a bunch of other schemes, this indeed is one of the better ones to use as the base.<div><br></div><div>Ping<br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques <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">As i pointed out in the RT area meeting, i believe that IF-MAP is a successful example of what can be achieved by network-wide schemas (vs network element schemas).<br>

<br>
The current spec is at:<br>
<a href="http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf" target="_blank">http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf</a><br>

<br>
<a href="http://if-map.org/" target="_blank">if-map.org</a> has lots of material on the use cases.<br>
<br>
As per my comment on the mic, i'd like to encourage the IRS to focus on data schemas that describe network state.<br>
<br>
thank you,<br>
&nbsp; Pedro.<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>
</blockquote></div><br></div>
</blockquote></div><br></div></div></body></html>
--Apple-Mail=_CA5C9F41-5E30-475F-99B1-B04343980483--

From: Ping Pan <[email-masked]>
Date: Thu, 2 Aug 2012 14:32:59 -0700
To: Pedro Roque Marques <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] if-map example

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

After playing around with a bunch of other schemes, this indeed is one of
the better ones to use as the base.

Ping

On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques <
[email-masked]> wrote:

> As i pointed out in the RT area meeting, i believe that IF-MAP is a
> successful example of what can be achieved by network-wide schemas (vs
> network element schemas).
>
> The current spec is at:
>
> http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf
>
> if-map.org has lots of material on the use cases.
>
> As per my comment on the mic, i'd like to encourage the IRS to focus on
> data schemas that describe network state.
>
> thank you,
>   Pedro.
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

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

After playing around with a bunch of other schemes, this indeed is one of the better ones to use as the base.<div><br></div><div>Ping<br><br><div class="gmail_quote">On Thu, Aug 2, 2012 at 11:07 AM, Pedro Roque Marques <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">As i pointed out in the RT area meeting, i believe that IF-MAP is a successful example of what can be achieved by network-wide schemas (vs network element schemas).<br>

<br>
The current spec is at:<br>
<a href="http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf" target="_blank">http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf</a><br>

<br>
<a href="http://if-map.org" target="_blank">if-map.org</a> has lots of material on the use cases.<br>
<br>
As per my comment on the mic, i&#39;d like to encourage the IRS to focus on data schemas that describe network state.<br>
<br>
thank you,<br>
Â  Pedro.<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>
</blockquote></div><br></div>

--e89a8f234c07308de804c64f2a2f--

From: Thomas Nadeau <[email-masked]>
To: Thomas Nadeau <[email-masked]>, Ning So <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 16:21:16 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3

        Apologies for the typo:

http://www.lucidvision.com/draft-ward-irs-framework-00e.pptx

On 8/2/12 1:03 PM, "Thomas Nadeau" <[email-masked]> wrote:

>
>        Apologies, they appear to not be there.  In the meantime, you can
>find
>them here:
>
>http://www.lucidvision.com/draft-ward-irs-framework-00d.ppt
>
>
>On 8/2/12 11:23 AM, "Thomas Nadeau" <[email-masked]> wrote:
>
>>They are at the bottom of the routing area meeting page:
>>
>>https://datatracker.ietf.org/meeting/84/agenda/rtgarea/
>>
>>From: Ning So <[email-masked]<mailto:[email-masked]>>
>>Reply-To: Ning So <[email-masked]<mailto:[email-masked]>>
>>Date: Thursday, August 2, 2012 10:46 AM
>>To: "[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>
>>Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3
>>
>>All,
>>
>>Is Alia's presentation loaded anywhere?  It's not on the meeting agenda
>>page.
>>
>>Ning
>>
>>From: "[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>>
>>To: [email-masked]<mailto:[email-masked]>
>>Sent: Thursday, August 2, 2012 1:20 AM
>>Subject: irs-discuss Digest, Vol 2, Issue 3
>>
>>----- Forwarded Message -----
>>
>>If you have received this digest without all the individual message
>>attachments you will need to update your digest options in your list
>>subscription.  To do so, go to
>>
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>Click the 'Unsubscribe or edit options' button, log in, and set "Get
>>MIME or Plain Text Digests?" to MIME.  You can set this option
>>globally for all the list digests you receive at this point.
>>
>>
>>
>>Send irs-discuss mailing list submissions to
>>    [email-masked]<mailto:[email-masked]>
>>
>>To subscribe or unsubscribe via the World Wide Web, visit
>>    https://www.ietf.org/mailman/listinfo/irs-discuss
>>or, via email, send a message with subject or body 'help' to
>>    [email-masked]<mailto:[email-masked]>
>>
>>You can reach the person managing the list at
>>    [email-masked]<mailto:[email-masked]>
>>
>>When replying, please edit your Subject line so it is more specific
>>than "Re: Contents of irs-discuss digest..."
>>
>>Today's Topics:
>>
>>  1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas)
>>  2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern)
>>  3. Re: IRS Problem Statement Posted (Susan Hares)
>>  4. Re: Thoughts on draft-ward-irs-framework (Russ White)
>>Thanks!
>>
>>On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Alia:
>>>
>>> I'll try to create a bibliography of things people should read.  It
>>>will be mid-next week since I'm away from my home library on the SDN
>>>topic.
>>>
>>> Sue
>>>
>>> -----Original Message-----
>>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>> Sent: Wednesday, August 01, 2012 3:51 PM
>>> To: Susan Hares
>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> Sue,
>>>
>>> I look forward to talking with you more off-line on the policy and
>>> local-pref research and issues.  If you have suggestions on good
>>> background research to read, by all means send it to the list so
>>> others can get up to speed as well.
>>>
>>> On the atomic transaction semantics question, let's get a bit further
>>> into the use-cases and framework - and then have a focused discussion.
>>>  I'm not opposed to it forever or if it is necessary - just would like
>>> to thoroughly analyze if it is a real requirement.
>>>
>>> Do others have opinions and perspective on this?
>>>
>>> Alia
>>>
>>> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>> Alia:
>>>>
>>>> The hierarchical of interfaces (To routing system) is one of the areas
>>>>that requires prioritization. The prioritization must be able to handle
>>>>"preempt me", "after you", and "after me".
>>>>
>>>> It is also key to understand that irs system must handle
>>>>multi-interfaces struggles at the lowest layer.  You need to look at
>>>>the MIF WG (+/-) for some of the struggles of mobility.
>>>>
>>>> -----Original Message-----
>>>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>>> Sent: Monday, July 30, 2012 6:33 PM
>>>> To: Susan Hares
>>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>>
>>>> Hi Sue,
>>>>
>>>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares
>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>> Joel and irs-folks:
>>>>>
>>>>> +1 on Joel.
>>>>>
>>>>>  Beyond your comments, the requirement prioritization of the
>>>>>interworking of these interfaces is not clearly delineated in this
>>>>>work. This type of prioritization and sequencing is key to
>>>>>multi-interfaces operation on the monitoring, configuration or
>>>>>insertion of information into the depth.
>>>>
>>>> [Alia] Can you further clarify, maybe with an example, which aspect
>>>> you are thinking of?  Do you mean the ability of an application to
>>>> access multiple sub-interfaces?  The interaction of operations
>>>> requested by differerent applications?
>>>>
>>>>> In addition, if you are going to do configuration with
>>>>>roll-forward/roll-back - you need a transaction based processing.
>>>>
>>>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>>>> drafts.  That was deliberate.  Of course, we can have a discussion
>>>> about whether or not some form of transactions might be desirable.  I
>>>> am concerned about their potentially heavy-weight nature.
>>>>
>>>>> Therefore, you've skipped even requiring the hard problems.
>>>>
>>>> [Alia] Can I optimistically pretend that means that the requirements
>>>> we do have don't seem too hard?  For the responsiveness and throughput
>>>> goals, I've put a stake in the ground to avoid transaction-based
>>>> semantics.  Naturally, the hordes can run over that stake, if
>>>> necessary.
>>>>
>>>> [Sue]: The requirements are necessary even if they are hard.
>>>>
>>>> [Alia] For the interaction between different layers of sub-interfaces,
>>>> I've been assuming that we'll define the interactions between the
>>>> layers based on how they are generally done.  For instance, perhaps we
>>>> standardize the idea of preference value - and then the RIB can pick
>>>> the best route based upon those preferences.  For interaction between
>>>> different applications, I think there's a mixture of
>>>> authorization/authentication to get right plus a good set of events
>>>> that an application could register for.
>>>>
>>>> [Sue]: As someone who has lived with "local pref" in BGP for a long
>>>>time, there is a bit more to unwrap in the statement.  However, it
>>>>breaks down to prioritization that is pre-set by preferences.
>>>>
>>>> The policy issues behind the local-pref setting have been studied by
>>>>the BGP policy community. This is substantial good work on this from
>>>>the academic researchers, vendors, and operator. Griffins, Rexford,
>>>>Bush, Feamster, ..... and lots others are much better on the theory
>>>>than I am.
>>>>
>>>>> Is this just the -00.draft?
>>>>
>>>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>>>> go along.  As I said, some of this is initially setting parts  out of
>>>> scope.
>>>>
>>>> ---> Scope == good.  Setting scope allows us to pick a piece of this
>>>>work and standardize it for interoperability.
>>>>
>>>> Alia
>>>>
>>>>> Sue
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From:
>>>>>[email-masked]<mailto:[email-masked]>
>>>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>>r
>>>>>g>] On Behalf Of Joel M. Halpern
>>>>> Sent: Monday, July 30, 2012 3:15 PM
>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>> Subject: Re: [irs-discuss] I-D Action:
>>>>>draft-ward-irs-framework-00.txt
>>>>>
>>>>> I am finding this document quite confusing.
>>>>>
>>>>> The primary confusion is that the document first says that it is
>>>>>about
>>>>> information that can not be manipulated with existing systems, and
>>>>>then
>>>>> proceeds to give a list of use cases all of which can be manipulated
>>>>> with existing systems at a suitable degree of abstraction.
>>>>>
>>>>> As a lesser confusion, the document says that "streaming" is
>>>>>important,
>>>>> but then describes "streaming" as "fast, interactive access."  That
>>>>>is
>>>>> not streaming.  And depending upon what one means by interactive,
>>>>>plenty
>>>>> of systems provide "fest, interactive access."  I realize the
>>>>>document
>>>>> later goes on tot talk about speed and frequency of state updates.
>>>>>But
>>>>> that section simply reasserts the earlier terms withotu better
>>>>> description or justification.
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>> On 7/30/2012 2:08 PM,
>>>>>[email-masked]<mailto:[email-masked]> wrote:
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>>directories.
>>>>>>
>>>>>>
>>>>>>      Title          : Interface to the Routing System Framework
>>>>>>      Author(s)      : Alia Atlas
>>>>>>                            Thomas Nadeau
>>>>>>                            Dave Ward
>>>>>>      Filename        : draft-ward-irs-framework-00.txt
>>>>>>      Pages          : 21
>>>>>>      Date            : 2012-07-30
>>>>>>
>>>>>> Abstract:
>>>>>>    This document describes a framework for a standard, programmatic
>>>>>>    interface for full-duplex, streaming state transfer in and out of
>>>>>>the
>>>>>>    Internet's routing system.  It lists the information that might
>>>>>>be
>>>>>>    exchanged over the interface, and describes the uses of an
>>>>>>interface
>>>>>>    to the Internet routing system.
>>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>With regard to transaction issues, we discussed this extensively when
>>doing ForCES.  We concluded that the answer we needed was "yes and no".
>>  That is, the protocol has mechanisms which can be used for
>>transactional integrity, including integrity across interactions with
>>multiple FEs.  However, the protocol does not require the CE to use
>>those mechanisms.  In fact, if it does not even want explicit acks (the
>>messages go over TCP), it can defer that until it gets to a good "please
>>confirm" point.
>>And in the efforts to use this later, having this range of options has
>>been useful.
>>
>>Yours,
>>Joel
>>
>>On 8/1/2012 6:51 PM, Alia Atlas wrote:
>>> Sue,
>>>
>>> I look forward to talking with you more off-line on the policy and
>>> local-pref research and issues.  If you have suggestions on good
>>> background research to read, by all means send it to the list so
>>> others can get up to speed as well.
>>>
>>> On the atomic transaction semantics question, let's get a bit further
>>> into the use-cases and framework - and then have a focused discussion.
>>>  I'm not opposed to it forever or if it is necessary - just would like
>>> to thoroughly analyze if it is a real requirement.
>>>
>>> Do others have opinions and perspective on this?
>>>
>>> Alia
>>>
>>> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>> Alia:
>>>>
>>>> The hierarchical of interfaces (To routing system) is one of the areas
>>>>that requires prioritization. The prioritization must be able to handle
>>>>"preempt me", "after you", and "after me".
>>>>
>>>> It is also key to understand that irs system must handle
>>>>multi-interfaces struggles at the lowest layer.  You need to look at
>>>>the MIF WG (+/-) for some of the struggles of mobility.
>>>>
>>>> -----Original Message-----
>>>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>>> Sent: Monday, July 30, 2012 6:33 PM
>>>> To: Susan Hares
>>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>>
>>>> Hi Sue,
>>>>
>>>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares
>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>> Joel and irs-folks:
>>>>>
>>>>> +1 on Joel.
>>>>>
>>>>>  Beyond your comments, the requirement prioritization of the
>>>>>interworking of these interfaces is not clearly delineated in this
>>>>>work. This type of prioritization and sequencing is key to
>>>>>multi-interfaces operation on the monitoring, configuration or
>>>>>insertion of information into the depth.
>>>>
>>>> [Alia] Can you further clarify, maybe with an example, which aspect
>>>> you are thinking of?  Do you mean the ability of an application to
>>>> access multiple sub-interfaces?  The interaction of operations
>>>> requested by differerent applications?
>>>>
>>>>> In addition, if you are going to do configuration with
>>>>>roll-forward/roll-back - you need a transaction based processing.
>>>>
>>>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>>>> drafts.  That was deliberate.  Of course, we can have a discussion
>>>> about whether or not some form of transactions might be desirable.  I
>>>> am concerned about their potentially heavy-weight nature.
>>>>
>>>>> Therefore, you've skipped even requiring the hard problems.
>>>>
>>>> [Alia] Can I optimistically pretend that means that the requirements
>>>> we do have don't seem too hard?  For the responsiveness and throughput
>>>> goals, I've put a stake in the ground to avoid transaction-based
>>>> semantics.  Naturally, the hordes can run over that stake, if
>>>> necessary.
>>>>
>>>> [Sue]: The requirements are necessary even if they are hard.
>>>>
>>>> [Alia] For the interaction between different layers of sub-interfaces,
>>>> I've been assuming that we'll define the interactions between the
>>>> layers based on how they are generally done.  For instance, perhaps we
>>>> standardize the idea of preference value - and then the RIB can pick
>>>> the best route based upon those preferences.  For interaction between
>>>> different applications, I think there's a mixture of
>>>> authorization/authentication to get right plus a good set of events
>>>> that an application could register for.
>>>>
>>>> [Sue]: As someone who has lived with "local pref" in BGP for a long
>>>>time, there is a bit more to unwrap in the statement.  However, it
>>>>breaks down to prioritization that is pre-set by preferences.
>>>>
>>>> The policy issues behind the local-pref setting have been studied by
>>>>the BGP policy community. This is substantial good work on this from
>>>>the academic researchers, vendors, and operator. Griffins, Rexford,
>>>>Bush, Feamster, ..... and lots others are much better on the theory
>>>>than I am.
>>>>
>>>>> Is this just the -00.draft?
>>>>
>>>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>>>> go along.  As I said, some of this is initially setting parts  out of
>>>> scope.
>>>>
>>>> ---> Scope == good.  Setting scope allows us to pick a piece of this
>>>>work and standardize it for interoperability.
>>>>
>>>> Alia
>>>>
>>>>> Sue
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From:
>>>>>[email-masked]<mailto:[email-masked]>
>>>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>>r
>>>>>g>] On Behalf Of Joel M. Halpern
>>>>> Sent: Monday, July 30, 2012 3:15 PM
>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>> Subject: Re: [irs-discuss] I-D Action:
>>>>>draft-ward-irs-framework-00.txt
>>>>>
>>>>> I am finding this document quite confusing.
>>>>>
>>>>> The primary confusion is that the document first says that it is
>>>>>about
>>>>> information that can not be manipulated with existing systems, and
>>>>>then
>>>>> proceeds to give a list of use cases all of which can be manipulated
>>>>> with existing systems at a suitable degree of abstraction.
>>>>>
>>>>> As a lesser confusion, the document says that "streaming" is
>>>>>important,
>>>>> but then describes "streaming" as "fast, interactive access."  That
>>>>>is
>>>>> not streaming.  And depending upon what one means by interactive,
>>>>>plenty
>>>>> of systems provide "fest, interactive access."  I realize the
>>>>>document
>>>>> later goes on tot talk about speed and frequency of state updates.
>>>>>But
>>>>> that section simply reasserts the earlier terms withotu better
>>>>> description or justification.
>>>>>
>>>>> Yours,
>>>>> Joel
>>>>>
>>>>> On 7/30/2012 2:08 PM,
>>>>>[email-masked]<mailto:[email-masked]> wrote:
>>>>>>
>>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>>directories.
>>>>>>
>>>>>>
>>>>>>        Title          : Interface to the Routing System Framework
>>>>>>        Author(s)      : Alia Atlas
>>>>>>                            Thomas Nadeau
>>>>>>                            Dave Ward
>>>>>>        Filename        : draft-ward-irs-framework-00.txt
>>>>>>        Pages          : 21
>>>>>>        Date            : 2012-07-30
>>>>>>
>>>>>> Abstract:
>>>>>>      This document describes a framework for a standard,
>>>>>>programmatic
>>>>>>      interface for full-duplex, streaming state transfer in and out
>>>>>>of the
>>>>>>      Internet's routing system.  It lists the information that might
>>>>>>be
>>>>>>      exchanged over the interface, and describes the uses of an
>>>>>>interface
>>>>>>      to the Internet routing system.
>>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>
>>Alia:
>>
>>I'm going to check with a colleague who has been doing lots of model work
>>to see if he's got a better.  More later.
>>
>>Sue
>>
>>-----Original Message-----
>>From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>Sent: Wednesday, August 01, 2012 3:41 PM
>>To: Susan Hares
>>Cc: Nitin Bahadur; James Kempf; Thomas Nadeau;
>>[email-masked]<mailto:[email-masked]>
>>Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>>Sue,
>>
>>In this case, I was thinking of "translating" from a "higher
>>abstraction layer" to a "lower abstraction layer".
>>
>>Do you have a better/different term to suggest?  I agree that clarity
>>of terminology is important.
>>
>>Alia
>>
>>On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Alia:
>>>
>>> +1 on abstraction + filters (abstract/detail) IRS fits at the routing
>>>control.
>>>
>>> The real question about translation is what the translation is doing.
>>>Is it translating one thing to another at the same layer of abstraction
>>>(e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail
>>>change.
>>>
>>> I define translation as the same layer of abstraction.  Some people
>>>suggest translation = abstract/detailing.  We first need a common way to
>>>talk about the difference.
>>>
>>> Sue
>>>
>>> By the way --- I'm thrilled about the pace of the discussion.
>>>
>>>
>>> -----Original Message-----
>>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>> Sent: Monday, July 30, 2012 6:40 PM
>>> To: Susan Hares
>>> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau;
>>>[email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>>
>>> Sue,
>>>
>>> I certainly agree that we want IRS to have the ability to express
>>> information at different abstraction layers and filtered on request.
>>>
>>> There may still be a gap between the "network OS abstractions" and IRS
>>> sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
>>> the bottom-up control strings.
>>>
>>> IMHO, it's reasonable to have an entity that manages the translation.
>>> For instance, one doesn't need a PCE-equiv in every application - nor
>>> in every router; that might be an entity in between.
>>>
>>> The quantity of information is part of why explicit filtering and
>>> hopefully abstraction layers should be built into the data-models.
>>>
>>> Alia
>>>
>>> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>> Nitin:
>>>>
>>>> Exposing some network intelligence can either be done in detail or in
>>>>some amount of summarization.
>>>> If you are doing detail, you have bandwidth issues. If you are doing
>>>>summarization or opacity, you are talking about layers of information.
>>>>
>>>> Apps need to find out what they need to get. They do not need all the
>>>>details - just the fact they can get from point A to Point B (or for
>>>>multi-cast B/C/D). They need to where they can go to date other
>>>>applications.  They need a match-maker for the application who
>>>>determine where the applications shall flow.  Now, if they are smart -
>>>>like people going out to eat - they pick several ways go to eat
>>>>traffic.
>>>>
>>>> The network orchestration then serves to be the paths to the place to
>>>>eat.  This can either be distributed or centralized.
>>>>
>>>> If we have an Interface to routing, it need to have a two-layer
>>>>concept of exposing information.
>>>>
>>>> Sue Hares
>>>>
>>>> -----Original Message-----
>>>> From:
>>>>[email-masked]<mailto:[email-masked]>
>>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>g
>>>>>] On Behalf Of Nitin Bahadur
>>>> Sent: Monday, July 30, 2012 3:33 PM
>>>> To: James Kempf; Thomas Nadeau;
>>>>[email-masked]<mailto:[email-masked]>
>>>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>>>
>>>> Hi James,
>>>>
>>>> This is not about splitting control plane and forwarding plane. It is
>>>>about exposing network intelligence in the network elements to an
>>>>external controller.
>>>> And it is about allowing an external controller to use that
>>>>information for enabling network-aware apps. And it is about allowing
>>>>apps to influence the
>>>> network element's RIB (not the FIB directly).
>>>>
>>>> Streaming is essential to allow for operations at scale...and avoid a
>>>>request/response gated mechanism.
>>>>
>>>> Hope that helps.
>>>>
>>>> Thanks
>>>> Nitin
>>>>
>>>> On 7/30/12 3:11 PM, "James Kempf"
>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>> I don't understand why streaming is specified in this draft. And I
>>>>don't understand why this draft isn't put in the Forces framework.
>>>>Forces is a framework explicitedly designed for device to controller
>>>>communication. Its major drawback it that it is a framework with a hole
>>>>in the middle, in that there are no specified devices. This draft would
>>>>fill that hole.
>>>>
>>>> I don't think it is necessary to have a problem statement for router
>>>>state update. Forces has already established that splitting the control
>>>>plane into a separate device is, in some cases, an attractive design
>>>>option. So I think this should be submitted to the Forces working
>>>>group, or, at least, recast in the Forces framework.
>>>>
>>>>                jak
>>>>
>>>>> -----Original Message-----
>>>>> From:
>>>>>[email-masked]<mailto:[email-masked]>
>>>>>
>>>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>>r
>>>>>g>] On Behalf Of Thomas Nadeau
>>>>> Sent: Monday, July 30, 2012 11:18 AM
>>>>> To: [email-masked]<mailto:[email-masked]>
>>>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>>>
>>>>>
>>>>>
>>>>> Please review and discuss.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Tom, Alia, Ward
>>>>>
>>>>>
>>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]<mailto:[email-masked]>
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>> Sue: Use cases are key.  The clarity of the use cases will guide us.
>>>Please send USE cases.
>>
>>Here are three I just threw together. We can talk about refining these
>>tomorrow, if you like... My fingers got tired before my brain did. :-)
>>
>>Russ
>>
>>==
>>Optimized Exit Use Case
>>
>>Assume you have a network where there are two possible exit points
>>towards any set of destinations. The cost of using these links varies by
>>time, and the quality of the links is highly variable, but not
>>necessarily related to the actual load the local network is putting on
>>them (in other words, these are oversubscribed links shared with other
>>parallel networks or customers with unpredictable traffic patterns).
>>What you'd like to do is to use the lowest cost link until the quality
>>of the link reaches a specific level, and then switch to the higher cost
>>link. The point at which this link switch might occur may vary based on
>>time of day, because the RTO on specific traffic levels varies by the
>>time of day as well.
>>
>>So you have a problem with multiple variables: link quality (apparently
>>random from your perspective), link cost (varies by time of day), return
>>on investment (varies by time of day). Combined with this you have
>>multiple exit points, and you must draw traffic from an inside network
>>as efficiently as possible to the best exit point, as determined by
>>these various factors.
>>
>>The only well defined way to resolve this problem is to feed the
>>variables to an off router controller, calculate the best exit point on
>>some periodic basis, and then feed this information back into the
>>routing table. All solutions that can solve this problem today use route
>>injection into BGP, static route injection, or some other means to
>>direct traffic --difficult and error prone mechanisms. All of these
>>solutions also draw traffic only along links between the edge routers
>>themselves to put traffic on the best possible outbound link.
>>
>>With IRS, the best path could be calculated using any number of custom
>>written mechanisms, and the routes injected into the right places in the
>>network to effect the most efficient drawing of traffic to the best exit
>>point. Changes in the network environment could quickly cause traffic to
>>be shifted to alternate exit points when circumstances dictate.
>>
>>==
>>Denial of Service
>>
>>FlowSpec is designed to allow an AS to push a filter upstream, with the
>>ultimate goal being to block the source of DDoS and other attacks as
>>close to the origin of those attacks as possible. There are some
>>situations, however, where you would prefer to block an attack at all
>>edges, or throughout an entire local network. For instance, you might
>>want to block the forwarding of traffic within your network while you
>>are pushing FlowSpec updates upstream to block the traffic closer to the
>>source, or you might be dealing with an attack originating from multiple
>>points within your own network.
>>
>>While these responses are possible with standard routing, there is a
>>strong case to be made that routing information should not be mixed with
>>security response information within the routing domain (within an AS).
>>Mixing these two types of information can make network management more
>>difficult, and slow down the repair of a network during large scale
>>failures. It would be simpler to have a single controller in a network
>>tied to the various attack detection mechanisms that could directly
>>install the correct routing information to pull all attack traffic to a
>>central location, or to simply route the traffic to a null interface.
>>
>>An related use is that of pulling unknown traffic through specific
>>devices for analysis. A network operator may not want to drive all
>>traffic through traffic analysis devices simply because of cost and
>>quality of service degredation. A network operator could use IRS to
>>directly modify the routing tables on devices in the path of unknown or
>>possibly dangerous flows so this traffic is pulled through the correct
>>monitoring and analysis devices.
>>
>>==
>>Remote Service Routing
>>
>>In hub and spoke overlay networks, there is always an issue with
>>balancing between the information held in the spoke routing table,
>>optimal routing through the network underlying the overlay, and
>>mobility. Most solutions in this space use some form of centralized
>>route server that acts as a directory of all reachable destinations and
>>next hops, a protocol by which spoke devices and this route server
>>communicate, and caches at the remote sites.
>>
>>An IRS solution would use the same elements, but with a different
>>control plane. Remote sites would register (or advertise through some
>>standard routing protocol, such as BGP), the reachable destinations at
>>each site, along with the address of the router (or other device) used
>>to reach that destination. These would, as always, be stored in a route
>>server (or several redundant route servers) at a central location.
>>
>>When a remote site sends a set of packets to the central location that
>>are eventually destined to some other remote site, the central location
>>can forward this traffic, but at the same time simply directly insert
>>the correct routing information into the remote site's routing table. If
>>the location of the destination changes, the route server can directly
>>modify the routing information at the remote site as needed.
>>An interesting aspect of this solution is that no new and specialized
>>protocols are needed between the remote sites and the centralized route
>>server(s). Normal routing protocols can be used to notify the
>>centralized route server(s) of modifications in reachability
>>information, and the route server(s) can respond as needed, based on
>>local algorithms optimized for a particular application or network. For
>>instance, short lived flows might be allowed to simply pass through the
>>hub site with no reaction, while longer lived flows might warrant a
>>specific route to be installed in the remote router. Algorithms can also
>>be developed that would optimize traffic flow through the overlay, and
>>also to remove routing entries from remote devices when they are no
>>longer needed based on far greater intelligence than simple non-use for
>>some period of time.
>>
>>==
>>
>>
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]<mailto:[email-masked]>
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>_______________________________________________
>>irs-discuss mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Thomas Nadeau <[email-masked]>
To: Ning So <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 16:03:49 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3

        Apologies, they appear to not be there.  In the meantime, you can find
them here:

http://www.lucidvision.com/draft-ward-irs-framework-00d.ppt

On 8/2/12 11:23 AM, "Thomas Nadeau" <[email-masked]> wrote:

>They are at the bottom of the routing area meeting page:
>
>https://datatracker.ietf.org/meeting/84/agenda/rtgarea/
>
>From: Ning So <[email-masked]<mailto:[email-masked]>>
>Reply-To: Ning So <[email-masked]<mailto:[email-masked]>>
>Date: Thursday, August 2, 2012 10:46 AM
>To: "[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3
>
>All,
>
>Is Alia's presentation loaded anywhere?  It's not on the meeting agenda
>page.
>
>Ning
>
>From: "[email-masked]<mailto:[email-masked]>"
><[email-masked]<mailto:[email-masked]>>
>To: [email-masked]<mailto:[email-masked]>
>Sent: Thursday, August 2, 2012 1:20 AM
>Subject: irs-discuss Digest, Vol 2, Issue 3
>
>----- Forwarded Message -----
>
>If you have received this digest without all the individual message
>attachments you will need to update your digest options in your list
>subscription.  To do so, go to
>
>https://www.ietf.org/mailman/listinfo/irs-discuss
>
>Click the 'Unsubscribe or edit options' button, log in, and set "Get
>MIME or Plain Text Digests?" to MIME.  You can set this option
>globally for all the list digests you receive at this point.
>
>
>
>Send irs-discuss mailing list submissions to
>    [email-masked]<mailto:[email-masked]>
>
>To subscribe or unsubscribe via the World Wide Web, visit
>    https://www.ietf.org/mailman/listinfo/irs-discuss
>or, via email, send a message with subject or body 'help' to
>    [email-masked]<mailto:[email-masked]>
>
>You can reach the person managing the list at
>    [email-masked]<mailto:[email-masked]>
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of irs-discuss digest..."
>
>Today's Topics:
>
>  1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas)
>  2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern)
>  3. Re: IRS Problem Statement Posted (Susan Hares)
>  4. Re: Thoughts on draft-ward-irs-framework (Russ White)
>Thanks!
>
>On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares
><[email-masked]<mailto:[email-masked]>> wrote:
>> Alia:
>>
>> I'll try to create a bibliography of things people should read.  It
>>will be mid-next week since I'm away from my home library on the SDN
>>topic.
>>
>> Sue
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>> Sent: Wednesday, August 01, 2012 3:51 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Sue,
>>
>> I look forward to talking with you more off-line on the policy and
>> local-pref research and issues.  If you have suggestions on good
>> background research to read, by all means send it to the list so
>> others can get up to speed as well.
>>
>> On the atomic transaction semantics question, let's get a bit further
>> into the use-cases and framework - and then have a focused discussion.
>>  I'm not opposed to it forever or if it is necessary - just would like
>> to thoroughly analyze if it is a real requirement.
>>
>> Do others have opinions and perspective on this?
>>
>> Alia
>>
>> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Alia:
>>>
>>> The hierarchical of interfaces (To routing system) is one of the areas
>>>that requires prioritization. The prioritization must be able to handle
>>>"preempt me", "after you", and "after me".
>>>
>>> It is also key to understand that irs system must handle
>>>multi-interfaces struggles at the lowest layer.  You need to look at
>>>the MIF WG (+/-) for some of the struggles of mobility.
>>>
>>> -----Original Message-----
>>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>> Sent: Monday, July 30, 2012 6:33 PM
>>> To: Susan Hares
>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> Hi Sue,
>>>
>>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>> Joel and irs-folks:
>>>>
>>>> +1 on Joel.
>>>>
>>>>  Beyond your comments, the requirement prioritization of the
>>>>interworking of these interfaces is not clearly delineated in this
>>>>work. This type of prioritization and sequencing is key to
>>>>multi-interfaces operation on the monitoring, configuration or
>>>>insertion of information into the depth.
>>>
>>> [Alia] Can you further clarify, maybe with an example, which aspect
>>> you are thinking of?  Do you mean the ability of an application to
>>> access multiple sub-interfaces?  The interaction of operations
>>> requested by differerent applications?
>>>
>>>> In addition, if you are going to do configuration with
>>>>roll-forward/roll-back - you need a transaction based processing.
>>>
>>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>>> drafts.  That was deliberate.  Of course, we can have a discussion
>>> about whether or not some form of transactions might be desirable.  I
>>> am concerned about their potentially heavy-weight nature.
>>>
>>>> Therefore, you've skipped even requiring the hard problems.
>>>
>>> [Alia] Can I optimistically pretend that means that the requirements
>>> we do have don't seem too hard?  For the responsiveness and throughput
>>> goals, I've put a stake in the ground to avoid transaction-based
>>> semantics.  Naturally, the hordes can run over that stake, if
>>> necessary.
>>>
>>> [Sue]: The requirements are necessary even if they are hard.
>>>
>>> [Alia] For the interaction between different layers of sub-interfaces,
>>> I've been assuming that we'll define the interactions between the
>>> layers based on how they are generally done.  For instance, perhaps we
>>> standardize the idea of preference value - and then the RIB can pick
>>> the best route based upon those preferences.  For interaction between
>>> different applications, I think there's a mixture of
>>> authorization/authentication to get right plus a good set of events
>>> that an application could register for.
>>>
>>> [Sue]: As someone who has lived with "local pref" in BGP for a long
>>>time, there is a bit more to unwrap in the statement.  However, it
>>>breaks down to prioritization that is pre-set by preferences.
>>>
>>> The policy issues behind the local-pref setting have been studied by
>>>the BGP policy community. This is substantial good work on this from
>>>the academic researchers, vendors, and operator. Griffins, Rexford,
>>>Bush, Feamster, ..... and lots others are much better on the theory
>>>than I am.
>>>
>>>> Is this just the -00.draft?
>>>
>>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>>> go along.  As I said, some of this is initially setting parts  out of
>>> scope.
>>>
>>> ---> Scope == good.  Setting scope allows us to pick a piece of this
>>>work and standardize it for interoperability.
>>>
>>> Alia
>>>
>>>> Sue
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From:
>>>>[email-masked]<mailto:[email-masked]>
>>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>g>] On Behalf Of Joel M. Halpern
>>>> Sent: Monday, July 30, 2012 3:15 PM
>>>> To: [email-masked]<mailto:[email-masked]>
>>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>>
>>>> I am finding this document quite confusing.
>>>>
>>>> The primary confusion is that the document first says that it is about
>>>> information that can not be manipulated with existing systems, and
>>>>then
>>>> proceeds to give a list of use cases all of which can be manipulated
>>>> with existing systems at a suitable degree of abstraction.
>>>>
>>>> As a lesser confusion, the document says that "streaming" is
>>>>important,
>>>> but then describes "streaming" as "fast, interactive access."  That is
>>>> not streaming.  And depending upon what one means by interactive,
>>>>plenty
>>>> of systems provide "fest, interactive access."  I realize the document
>>>> later goes on tot talk about speed and frequency of state updates.
>>>>But
>>>> that section simply reasserts the earlier terms withotu better
>>>> description or justification.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 7/30/2012 2:08 PM,
>>>>[email-masked]<mailto:[email-masked]> wrote:
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>directories.
>>>>>
>>>>>
>>>>>      Title          : Interface to the Routing System Framework
>>>>>      Author(s)      : Alia Atlas
>>>>>                            Thomas Nadeau
>>>>>                            Dave Ward
>>>>>      Filename        : draft-ward-irs-framework-00.txt
>>>>>      Pages          : 21
>>>>>      Date            : 2012-07-30
>>>>>
>>>>> Abstract:
>>>>>    This document describes a framework for a standard, programmatic
>>>>>    interface for full-duplex, streaming state transfer in and out of
>>>>>the
>>>>>    Internet's routing system.  It lists the information that might be
>>>>>    exchanged over the interface, and describes the uses of an
>>>>>interface
>>>>>    to the Internet routing system.
>>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>With regard to transaction issues, we discussed this extensively when
>doing ForCES.  We concluded that the answer we needed was "yes and no".
>  That is, the protocol has mechanisms which can be used for
>transactional integrity, including integrity across interactions with
>multiple FEs.  However, the protocol does not require the CE to use
>those mechanisms.  In fact, if it does not even want explicit acks (the
>messages go over TCP), it can defer that until it gets to a good "please
>confirm" point.
>And in the efforts to use this later, having this range of options has
>been useful.
>
>Yours,
>Joel
>
>On 8/1/2012 6:51 PM, Alia Atlas wrote:
>> Sue,
>>
>> I look forward to talking with you more off-line on the policy and
>> local-pref research and issues.  If you have suggestions on good
>> background research to read, by all means send it to the list so
>> others can get up to speed as well.
>>
>> On the atomic transaction semantics question, let's get a bit further
>> into the use-cases and framework - and then have a focused discussion.
>>  I'm not opposed to it forever or if it is necessary - just would like
>> to thoroughly analyze if it is a real requirement.
>>
>> Do others have opinions and perspective on this?
>>
>> Alia
>>
>> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Alia:
>>>
>>> The hierarchical of interfaces (To routing system) is one of the areas
>>>that requires prioritization. The prioritization must be able to handle
>>>"preempt me", "after you", and "after me".
>>>
>>> It is also key to understand that irs system must handle
>>>multi-interfaces struggles at the lowest layer.  You need to look at
>>>the MIF WG (+/-) for some of the struggles of mobility.
>>>
>>> -----Original Message-----
>>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>>> Sent: Monday, July 30, 2012 6:33 PM
>>> To: Susan Hares
>>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> Hi Sue,
>>>
>>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>> Joel and irs-folks:
>>>>
>>>> +1 on Joel.
>>>>
>>>>  Beyond your comments, the requirement prioritization of the
>>>>interworking of these interfaces is not clearly delineated in this
>>>>work. This type of prioritization and sequencing is key to
>>>>multi-interfaces operation on the monitoring, configuration or
>>>>insertion of information into the depth.
>>>
>>> [Alia] Can you further clarify, maybe with an example, which aspect
>>> you are thinking of?  Do you mean the ability of an application to
>>> access multiple sub-interfaces?  The interaction of operations
>>> requested by differerent applications?
>>>
>>>> In addition, if you are going to do configuration with
>>>>roll-forward/roll-back - you need a transaction based processing.
>>>
>>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>>> drafts.  That was deliberate.  Of course, we can have a discussion
>>> about whether or not some form of transactions might be desirable.  I
>>> am concerned about their potentially heavy-weight nature.
>>>
>>>> Therefore, you've skipped even requiring the hard problems.
>>>
>>> [Alia] Can I optimistically pretend that means that the requirements
>>> we do have don't seem too hard?  For the responsiveness and throughput
>>> goals, I've put a stake in the ground to avoid transaction-based
>>> semantics.  Naturally, the hordes can run over that stake, if
>>> necessary.
>>>
>>> [Sue]: The requirements are necessary even if they are hard.
>>>
>>> [Alia] For the interaction between different layers of sub-interfaces,
>>> I've been assuming that we'll define the interactions between the
>>> layers based on how they are generally done.  For instance, perhaps we
>>> standardize the idea of preference value - and then the RIB can pick
>>> the best route based upon those preferences.  For interaction between
>>> different applications, I think there's a mixture of
>>> authorization/authentication to get right plus a good set of events
>>> that an application could register for.
>>>
>>> [Sue]: As someone who has lived with "local pref" in BGP for a long
>>>time, there is a bit more to unwrap in the statement.  However, it
>>>breaks down to prioritization that is pre-set by preferences.
>>>
>>> The policy issues behind the local-pref setting have been studied by
>>>the BGP policy community. This is substantial good work on this from
>>>the academic researchers, vendors, and operator. Griffins, Rexford,
>>>Bush, Feamster, ..... and lots others are much better on the theory
>>>than I am.
>>>
>>>> Is this just the -00.draft?
>>>
>>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>>> go along.  As I said, some of this is initially setting parts  out of
>>> scope.
>>>
>>> ---> Scope == good.  Setting scope allows us to pick a piece of this
>>>work and standardize it for interoperability.
>>>
>>> Alia
>>>
>>>> Sue
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From:
>>>>[email-masked]<mailto:[email-masked]>
>>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>g>] On Behalf Of Joel M. Halpern
>>>> Sent: Monday, July 30, 2012 3:15 PM
>>>> To: [email-masked]<mailto:[email-masked]>
>>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>>
>>>> I am finding this document quite confusing.
>>>>
>>>> The primary confusion is that the document first says that it is about
>>>> information that can not be manipulated with existing systems, and
>>>>then
>>>> proceeds to give a list of use cases all of which can be manipulated
>>>> with existing systems at a suitable degree of abstraction.
>>>>
>>>> As a lesser confusion, the document says that "streaming" is
>>>>important,
>>>> but then describes "streaming" as "fast, interactive access."  That is
>>>> not streaming.  And depending upon what one means by interactive,
>>>>plenty
>>>> of systems provide "fest, interactive access."  I realize the document
>>>> later goes on tot talk about speed and frequency of state updates.
>>>>But
>>>> that section simply reasserts the earlier terms withotu better
>>>> description or justification.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 7/30/2012 2:08 PM,
>>>>[email-masked]<mailto:[email-masked]> wrote:
>>>>>
>>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>>directories.
>>>>>
>>>>>
>>>>>        Title          : Interface to the Routing System Framework
>>>>>        Author(s)      : Alia Atlas
>>>>>                            Thomas Nadeau
>>>>>                            Dave Ward
>>>>>        Filename        : draft-ward-irs-framework-00.txt
>>>>>        Pages          : 21
>>>>>        Date            : 2012-07-30
>>>>>
>>>>> Abstract:
>>>>>      This document describes a framework for a standard, programmatic
>>>>>      interface for full-duplex, streaming state transfer in and out
>>>>>of the
>>>>>      Internet's routing system.  It lists the information that might
>>>>>be
>>>>>      exchanged over the interface, and describes the uses of an
>>>>>interface
>>>>>      to the Internet routing system.
>>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>
>Alia:
>
>I'm going to check with a colleague who has been doing lots of model work
>to see if he's got a better.  More later.
>
>Sue
>
>-----Original Message-----
>From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>Sent: Wednesday, August 01, 2012 3:41 PM
>To: Susan Hares
>Cc: Nitin Bahadur; James Kempf; Thomas Nadeau;
>[email-masked]<mailto:[email-masked]>
>Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
>Sue,
>
>In this case, I was thinking of "translating" from a "higher
>abstraction layer" to a "lower abstraction layer".
>
>Do you have a better/different term to suggest?  I agree that clarity
>of terminology is important.
>
>Alia
>
>On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares
><[email-masked]<mailto:[email-masked]>> wrote:
>> Alia:
>>
>> +1 on abstraction + filters (abstract/detail) IRS fits at the routing
>>control.
>>
>> The real question about translation is what the translation is doing.
>>Is it translating one thing to another at the same layer of abstraction
>>(e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail
>>change.
>>
>> I define translation as the same layer of abstraction.  Some people
>>suggest translation = abstract/detailing.  We first need a common way to
>>talk about the difference.
>>
>> Sue
>>
>> By the way --- I'm thrilled about the pace of the discussion.
>>
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>> Sent: Monday, July 30, 2012 6:40 PM
>> To: Susan Hares
>> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau;
>>[email-masked]<mailto:[email-masked]>
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Sue,
>>
>> I certainly agree that we want IRS to have the ability to express
>> information at different abstraction layers and filtered on request.
>>
>> There may still be a gap between the "network OS abstractions" and IRS
>> sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
>> the bottom-up control strings.
>>
>> IMHO, it's reasonable to have an entity that manages the translation.
>> For instance, one doesn't need a PCE-equiv in every application - nor
>> in every router; that might be an entity in between.
>>
>> The quantity of information is part of why explicit filtering and
>> hopefully abstraction layers should be built into the data-models.
>>
>> Alia
>>
>> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares
>><[email-masked]<mailto:[email-masked]>> wrote:
>>> Nitin:
>>>
>>> Exposing some network intelligence can either be done in detail or in
>>>some amount of summarization.
>>> If you are doing detail, you have bandwidth issues. If you are doing
>>>summarization or opacity, you are talking about layers of information.
>>>
>>> Apps need to find out what they need to get. They do not need all the
>>>details - just the fact they can get from point A to Point B (or for
>>>multi-cast B/C/D). They need to where they can go to date other
>>>applications.  They need a match-maker for the application who
>>>determine where the applications shall flow.  Now, if they are smart -
>>>like people going out to eat - they pick several ways go to eat traffic.
>>>
>>> The network orchestration then serves to be the paths to the place to
>>>eat.  This can either be distributed or centralized.
>>>
>>> If we have an Interface to routing, it need to have a two-layer
>>>concept of exposing information.
>>>
>>> Sue Hares
>>>
>>> -----Original Message-----
>>> From:
>>>[email-masked]<mailto:[email-masked]>
>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>] On Behalf Of Nitin Bahadur
>>> Sent: Monday, July 30, 2012 3:33 PM
>>> To: James Kempf; Thomas Nadeau;
>>>[email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>>
>>> Hi James,
>>>
>>> This is not about splitting control plane and forwarding plane. It is
>>>about exposing network intelligence in the network elements to an
>>>external controller.
>>> And it is about allowing an external controller to use that
>>>information for enabling network-aware apps. And it is about allowing
>>>apps to influence the
>>> network element's RIB (not the FIB directly).
>>>
>>> Streaming is essential to allow for operations at scale...and avoid a
>>>request/response gated mechanism.
>>>
>>> Hope that helps.
>>>
>>> Thanks
>>> Nitin
>>>
>>> On 7/30/12 3:11 PM, "James Kempf"
>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>
>>> I don't understand why streaming is specified in this draft. And I
>>>don't understand why this draft isn't put in the Forces framework.
>>>Forces is a framework explicitedly designed for device to controller
>>>communication. Its major drawback it that it is a framework with a hole
>>>in the middle, in that there are no specified devices. This draft would
>>>fill that hole.
>>>
>>> I don't think it is necessary to have a problem statement for router
>>>state update. Forces has already established that splitting the control
>>>plane into a separate device is, in some cases, an attractive design
>>>option. So I think this should be submitted to the Forces working
>>>group, or, at least, recast in the Forces framework.
>>>
>>>                jak
>>>
>>>> -----Original Message-----
>>>> From:
>>>>[email-masked]<mailto:[email-masked]>
>>>>
>>>>[mailto:[email-masked]<mailto:[email-masked]
>>>>g>] On Behalf Of Thomas Nadeau
>>>> Sent: Monday, July 30, 2012 11:18 AM
>>>> To: [email-masked]<mailto:[email-masked]>
>>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>>
>>>>
>>>>
>>>> Please review and discuss.
>>>>
>>>> Thanks,
>>>>
>>>> Tom, Alia, Ward
>>>>
>>>>
>>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>>
>>>>
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]<mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>> Sue: Use cases are key.  The clarity of the use cases will guide us.
>>Please send USE cases.
>
>Here are three I just threw together. We can talk about refining these
>tomorrow, if you like... My fingers got tired before my brain did. :-)
>
>Russ
>
>==
>Optimized Exit Use Case
>
>Assume you have a network where there are two possible exit points
>towards any set of destinations. The cost of using these links varies by
>time, and the quality of the links is highly variable, but not
>necessarily related to the actual load the local network is putting on
>them (in other words, these are oversubscribed links shared with other
>parallel networks or customers with unpredictable traffic patterns).
>What you'd like to do is to use the lowest cost link until the quality
>of the link reaches a specific level, and then switch to the higher cost
>link. The point at which this link switch might occur may vary based on
>time of day, because the RTO on specific traffic levels varies by the
>time of day as well.
>
>So you have a problem with multiple variables: link quality (apparently
>random from your perspective), link cost (varies by time of day), return
>on investment (varies by time of day). Combined with this you have
>multiple exit points, and you must draw traffic from an inside network
>as efficiently as possible to the best exit point, as determined by
>these various factors.
>
>The only well defined way to resolve this problem is to feed the
>variables to an off router controller, calculate the best exit point on
>some periodic basis, and then feed this information back into the
>routing table. All solutions that can solve this problem today use route
>injection into BGP, static route injection, or some other means to
>direct traffic --difficult and error prone mechanisms. All of these
>solutions also draw traffic only along links between the edge routers
>themselves to put traffic on the best possible outbound link.
>
>With IRS, the best path could be calculated using any number of custom
>written mechanisms, and the routes injected into the right places in the
>network to effect the most efficient drawing of traffic to the best exit
>point. Changes in the network environment could quickly cause traffic to
>be shifted to alternate exit points when circumstances dictate.
>
>==
>Denial of Service
>
>FlowSpec is designed to allow an AS to push a filter upstream, with the
>ultimate goal being to block the source of DDoS and other attacks as
>close to the origin of those attacks as possible. There are some
>situations, however, where you would prefer to block an attack at all
>edges, or throughout an entire local network. For instance, you might
>want to block the forwarding of traffic within your network while you
>are pushing FlowSpec updates upstream to block the traffic closer to the
>source, or you might be dealing with an attack originating from multiple
>points within your own network.
>
>While these responses are possible with standard routing, there is a
>strong case to be made that routing information should not be mixed with
>security response information within the routing domain (within an AS).
>Mixing these two types of information can make network management more
>difficult, and slow down the repair of a network during large scale
>failures. It would be simpler to have a single controller in a network
>tied to the various attack detection mechanisms that could directly
>install the correct routing information to pull all attack traffic to a
>central location, or to simply route the traffic to a null interface.
>
>An related use is that of pulling unknown traffic through specific
>devices for analysis. A network operator may not want to drive all
>traffic through traffic analysis devices simply because of cost and
>quality of service degredation. A network operator could use IRS to
>directly modify the routing tables on devices in the path of unknown or
>possibly dangerous flows so this traffic is pulled through the correct
>monitoring and analysis devices.
>
>==
>Remote Service Routing
>
>In hub and spoke overlay networks, there is always an issue with
>balancing between the information held in the spoke routing table,
>optimal routing through the network underlying the overlay, and
>mobility. Most solutions in this space use some form of centralized
>route server that acts as a directory of all reachable destinations and
>next hops, a protocol by which spoke devices and this route server
>communicate, and caches at the remote sites.
>
>An IRS solution would use the same elements, but with a different
>control plane. Remote sites would register (or advertise through some
>standard routing protocol, such as BGP), the reachable destinations at
>each site, along with the address of the router (or other device) used
>to reach that destination. These would, as always, be stored in a route
>server (or several redundant route servers) at a central location.
>
>When a remote site sends a set of packets to the central location that
>are eventually destined to some other remote site, the central location
>can forward this traffic, but at the same time simply directly insert
>the correct routing information into the remote site's routing table. If
>the location of the destination changes, the route server can directly
>modify the routing information at the remote site as needed.
>An interesting aspect of this solution is that no new and specialized
>protocols are needed between the remote sites and the centralized route
>server(s). Normal routing protocols can be used to notify the
>centralized route server(s) of modifications in reachability
>information, and the route server(s) can respond as needed, based on
>local algorithms optimized for a particular application or network. For
>instance, short lived flows might be allowed to simply pass through the
>hub site with no reaction, while longer lived flows might warrant a
>specific route to be installed in the remote router. Algorithms can also
>be developed that would optimize traffic flow through the overlay, and
>also to remove routing entries from remote devices when they are no
>longer needed based on far greater intelligence than simple non-use for
>some period of time.
>
>==
>
>
>_______________________________________________
>irs-discuss mailing list
>[email-masked]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Thomas Nadeau <[email-masked]>
To: Ning So <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 2 Aug 2012 14:23:46 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3

They are at the bottom of the routing area meeting page:

https://datatracker.ietf.org/meeting/84/agenda/rtgarea/

From: Ning So <[email-masked]<mailto:[email-masked]>>
Reply-To: Ning So <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 2, 2012 10:46 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3

All,

Is Alia's presentation loaded anywhere?  It's not on the meeting agenda page.

Ning

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
To: [email-masked]<mailto:[email-masked]>
Sent: Thursday, August 2, 2012 1:20 AM
Subject: irs-discuss Digest, Vol 2, Issue 3

----- Forwarded Message -----

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to

https://www.ietf.org/mailman/listinfo/irs-discuss

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send irs-discuss mailing list submissions to
    [email-masked]<mailto:[email-masked]>

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/irs-discuss
or, via email, send a message with subject or body 'help' to
    [email-masked]<mailto:[email-masked]>

You can reach the person managing the list at
    [email-masked]<mailto:[email-masked]>

When replying, please edit your Subject line so it is more specific
than "Re: Contents of irs-discuss digest..."

Today's Topics:

  1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas)
  2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern)
  3. Re: IRS Problem Statement Posted (Susan Hares)
  4. Re: Thoughts on draft-ward-irs-framework (Russ White)
Thanks!

On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
> Alia:
>
> I'll try to create a bibliography of things people should read.  It will be mid-next week since I'm away from my home library on the SDN topic.
>
> Sue
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Wednesday, August 01, 2012 3:51 PM
> To: Susan Hares
> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?  Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.  But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [email-masked]<mailto:[email-masked]> wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>      Title          : Interface to the Routing System Framework
>>>>      Author(s)      : Alia Atlas
>>>>                            Thomas Nadeau
>>>>                            Dave Ward
>>>>      Filename        : draft-ward-irs-framework-00.txt
>>>>      Pages          : 21
>>>>      Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>    This document describes a framework for a standard, programmatic
>>>>    interface for full-duplex, streaming state transfer in and out of the
>>>>    Internet's routing system.  It lists the information that might be
>>>>    exchanged over the interface, and describes the uses of an interface
>>>>    to the Internet routing system.
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss

With regard to transaction issues, we discussed this extensively when
doing ForCES.  We concluded that the answer we needed was "yes and no".
  That is, the protocol has mechanisms which can be used for
transactional integrity, including integrity across interactions with
multiple FEs.  However, the protocol does not require the CE to use
those mechanisms.  In fact, if it does not even want explicit acks (the
messages go over TCP), it can defer that until it gets to a good "please
confirm" point.
And in the efforts to use this later, having this range of options has
been useful.

Yours,
Joel

On 8/1/2012 6:51 PM, Alia Atlas wrote:
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [email-masked]<mailto:[email-masked]>
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?  Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [email-masked]<mailto:[email-masked]>
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.  But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [email-masked]<mailto:[email-masked]> wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>        Title          : Interface to the Routing System Framework
>>>>        Author(s)      : Alia Atlas
>>>>                            Thomas Nadeau
>>>>                            Dave Ward
>>>>        Filename        : draft-ward-irs-framework-00.txt
>>>>        Pages          : 21
>>>>        Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>      This document describes a framework for a standard, programmatic
>>>>      interface for full-duplex, streaming state transfer in and out of the
>>>>      Internet's routing system.  It lists the information that might be
>>>>      exchanged over the interface, and describes the uses of an interface
>>>>      to the Internet routing system.
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>

Alia:

I'm going to check with a colleague who has been doing lots of model work to see if he's got a better.  More later.

Sue

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 01, 2012 3:41 PM
To: Susan Hares
Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]<mailto:[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Sue,

In this case, I was thinking of "translating" from a "higher
abstraction layer" to a "lower abstraction layer".

Do you have a better/different term to suggest?  I agree that clarity
of terminology is important.

Alia

On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
> Alia:
>
> +1 on abstraction + filters (abstract/detail) IRS fits at the routing control.
>
> The real question about translation is what the translation is doing.  Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change.
>
> I define translation as the same layer of abstraction.  Some people suggest translation = abstract/detailing.  We first need a common way to talk about the difference.
>
> Sue
>
> By the way --- I'm thrilled about the pace of the discussion.
>
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Monday, July 30, 2012 6:40 PM
> To: Susan Hares
> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]<mailto:[email-masked]>
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Sue,
>
> I certainly agree that we want IRS to have the ability to express
> information at different abstraction layers and filtered on request.
>
> There may still be a gap between the "network OS abstractions" and IRS
> sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
> the bottom-up control strings.
>
> IMHO, it's reasonable to have an entity that manages the translation.
> For instance, one doesn't need a PCE-equiv in every application - nor
> in every router; that might be an entity in between.
>
> The quantity of information is part of why explicit filtering and
> hopefully abstraction layers should be built into the data-models.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked]<mailto:[email-masked]>> wrote:
>> Nitin:
>>
>> Exposing some network intelligence can either be done in detail or in some amount of summarization.
>> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information.
>>
>> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.
>>
>> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.
>>
>> If we have an Interface to routing, it need to have a two-layer concept of exposing information.
>>
>> Sue Hares
>>
>> -----Original Message-----
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nitin Bahadur
>> Sent: Monday, July 30, 2012 3:33 PM
>> To: James Kempf; Thomas Nadeau; [email-masked]<mailto:[email-masked]>
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Hi James,
>>
>> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
>> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
>> network element's RIB (not the FIB directly).
>>
>> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
>>
>> Hope that helps.
>>
>> Thanks
>> Nitin
>>
>> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]<mailto:[email-masked]>> wrote:
>>
>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>
>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>
>>                jak
>>
>>> -----Original Message-----
>>> From: [email-masked]<mailto:[email-masked]>
>>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Nadeau
>>> Sent: Monday, July 30, 2012 11:18 AM
>>> To: [email-masked]<mailto:[email-masked]>
>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>
>>>
>>>
>>> Please review and discuss.
>>>
>>> Thanks,
>>>
>>> Tom, Alia, Ward
>>>
>>>
>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]<mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]<mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/irs-discuss

> Sue: Use cases are key.  The clarity of the use cases will guide us.  Please send USE cases.

Here are three I just threw together. We can talk about refining these
tomorrow, if you like... My fingers got tired before my brain did. :-)

Russ

==
Optimized Exit Use Case

Assume you have a network where there are two possible exit points
towards any set of destinations. The cost of using these links varies by
time, and the quality of the links is highly variable, but not
necessarily related to the actual load the local network is putting on
them (in other words, these are oversubscribed links shared with other
parallel networks or customers with unpredictable traffic patterns).
What you'd like to do is to use the lowest cost link until the quality
of the link reaches a specific level, and then switch to the higher cost
link. The point at which this link switch might occur may vary based on
time of day, because the RTO on specific traffic levels varies by the
time of day as well.

So you have a problem with multiple variables: link quality (apparently
random from your perspective), link cost (varies by time of day), return
on investment (varies by time of day). Combined with this you have
multiple exit points, and you must draw traffic from an inside network
as efficiently as possible to the best exit point, as determined by
these various factors.

The only well defined way to resolve this problem is to feed the
variables to an off router controller, calculate the best exit point on
some periodic basis, and then feed this information back into the
routing table. All solutions that can solve this problem today use route
injection into BGP, static route injection, or some other means to
direct traffic --difficult and error prone mechanisms. All of these
solutions also draw traffic only along links between the edge routers
themselves to put traffic on the best possible outbound link.

With IRS, the best path could be calculated using any number of custom
written mechanisms, and the routes injected into the right places in the
network to effect the most efficient drawing of traffic to the best exit
point. Changes in the network environment could quickly cause traffic to
be shifted to alternate exit points when circumstances dictate.

==
Denial of Service

FlowSpec is designed to allow an AS to push a filter upstream, with the
ultimate goal being to block the source of DDoS and other attacks as
close to the origin of those attacks as possible. There are some
situations, however, where you would prefer to block an attack at all
edges, or throughout an entire local network. For instance, you might
want to block the forwarding of traffic within your network while you
are pushing FlowSpec updates upstream to block the traffic closer to the
source, or you might be dealing with an attack originating from multiple
points within your own network.

While these responses are possible with standard routing, there is a
strong case to be made that routing information should not be mixed with
security response information within the routing domain (within an AS).
Mixing these two types of information can make network management more
difficult, and slow down the repair of a network during large scale
failures. It would be simpler to have a single controller in a network
tied to the various attack detection mechanisms that could directly
install the correct routing information to pull all attack traffic to a
central location, or to simply route the traffic to a null interface.

An related use is that of pulling unknown traffic through specific
devices for analysis. A network operator may not want to drive all
traffic through traffic analysis devices simply because of cost and
quality of service degredation. A network operator could use IRS to
directly modify the routing tables on devices in the path of unknown or
possibly dangerous flows so this traffic is pulled through the correct
monitoring and analysis devices.

==
Remote Service Routing

In hub and spoke overlay networks, there is always an issue with
balancing between the information held in the spoke routing table,
optimal routing through the network underlying the overlay, and
mobility. Most solutions in this space use some form of centralized
route server that acts as a directory of all reachable destinations and
next hops, a protocol by which spoke devices and this route server
communicate, and caches at the remote sites.

An IRS solution would use the same elements, but with a different
control plane. Remote sites would register (or advertise through some
standard routing protocol, such as BGP), the reachable destinations at
each site, along with the address of the router (or other device) used
to reach that destination. These would, as always, be stored in a route
server (or several redundant route servers) at a central location.

When a remote site sends a set of packets to the central location that
are eventually destined to some other remote site, the central location
can forward this traffic, but at the same time simply directly insert
the correct routing information into the remote site's routing table. If
the location of the destination changes, the route server can directly
modify the routing information at the remote site as needed.
An interesting aspect of this solution is that no new and specialized
protocols are needed between the remote sites and the centralized route
server(s). Normal routing protocols can be used to notify the
centralized route server(s) of modifications in reachability
information, and the route server(s) can respond as needed, based on
local algorithms optimized for a particular application or network. For
instance, short lived flows might be allowed to simply pass through the
hub site with no reaction, while longer lived flows might warrant a
specific route to be installed in the remote router. Algorithms can also
be developed that would optimize traffic flow through the overlay, and
also to remove routing entries from remote devices when they are no
longer needed based on far greater intelligence than simple non-use for
some period of time.

==

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

From: Thomas Nadeau <[email-masked]>
To: "[email-masked]" <[email-masked]>, Alia Atlas <[email-masked]>
Date: Thu, 2 Aug 2012 14:22:23 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Clarification questions ...

On 8/2/12 10:45 AM, "Robert Raszuk" <[email-masked]> wrote:

>Q1:
>
>I have seen a framework slide showing IRS Agent withing the router.
>
>I would like to clarify if you are going to have such IRS Agent in each
>router participating in given (maybe new) service in the AS ? How many
>IRS clients your envision ?
>
>Is the model of 1000s of IRS agents talking to 10s of IRS clients as
>example ?

	That¹s been a bit of confusion.  The "agent" is the IRS interface on the
router. You could certainly have more htan one, but your implementation
would have to coordinate internally to make sure they can work together.
In the slides, its a logical representation.  Similarly, the "client"
component, is in the simple case, just the lib you import into the
application that understands the protocol; its not necessarily a
stand-alone thing.

>
>Q2:
>
>Is data currently distributed by routing protocols explicitly prohibited
>to be also distributed by IRS overlay and send to the routers by TBD IRS
>channel ?

	I think that is a reasonable question to ask.  I personally see it as
being valid to do both.

	--Tom

>
>Thx a lot !
>R.
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

From: Pedro Roque Marques <[email-masked]>
Date: Thu, 2 Aug 2012 11:07:40 -0700
To: [email-masked]
Subject: [irs-discuss] if-map example

As i pointed out in the RT area meeting, i believe that IF-MAP is a successful example of what can be achieved by network-wide schemas (vs network element schemas).

The current spec is at:
http://www.trustedcomputinggroup.org/files/resource_files/2888CAD9-1A4B-B294-D0ED95712B121FEF/TNC_IFMAP_v2_1r15.pdf

if-map.org has lots of material on the use cases.

As per my comment on the mic, i'd like to encourage the IRS to focus on data schemas that describe network state.

thank you,
  Pedro.

Date: Thu, 02 Aug 2012 19:52:58 +0200
From: Julien Meuric <[email-masked]>
Organization: France Telecom
To: Ning So <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3

http://www.ietf.org/proceedings/84/slides/slides-84-rtgarea-3.pptx (from 
https://datatracker.ietf.org/meeting/84/materials.html)

Julien

Le 02/08/2012 19:46, Ning So a écrit :
> All,
> Is Alia's presentation loaded anywhere?  It's not on the meeting 
> agenda page.
> Ning
>
> *From:* "[email-masked]" <[email-masked]>
> *To:* [email-masked]
> *Sent:* Thursday, August 2, 2012 1:20 AM
> *Subject:* irs-discuss Digest, Vol 2, Issue 3
>
> ----- Forwarded Message -----
>
> If you have received this digest without all the individual message
> attachments you will need to update your digest options in your list
> subscription.  To do so, go to
>
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> Click the 'Unsubscribe or edit options' button, log in, and set "Get
> MIME or Plain Text Digests?" to MIME.  You can set this option
> globally for all the list digests you receive at this point.
>
>
>
> Send irs-discuss mailing list submissions to
> [email-masked] <mailto:[email-masked]>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.ietf.org/mailman/listinfo/irs-discuss
> or, via email, send a message with subject or body 'help' to
> [email-masked] <mailto:[email-masked]>
>
> You can reach the person managing the list at
> [email-masked] <mailto:[email-masked]>
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of irs-discuss digest..."
>
> Today's Topics:
>
>   1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas)
>   2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern)
>   3. Re: IRS Problem Statement Posted (Susan Hares)
>   4. Re: Thoughts on draft-ward-irs-framework (Russ White)
> Thanks!
>
> On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > Alia:
> >
> > I'll try to create a bibliography of things people should read.  It 
> will be mid-next week since I'm away from my home library on the SDN 
> topic.
> >
> > Sue
> >
> > -----Original Message-----
> > From: Alia Atlas [mailto:[email-masked] <mailto:[email-masked]>]
> > Sent: Wednesday, August 01, 2012 3:51 PM
> > To: Susan Hares
> > Cc: Joel M. Halpern; [email-masked] <mailto:[email-masked]>
> > Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
> >
> > Sue,
> >
> > I look forward to talking with you more off-line on the policy and
> > local-pref research and issues.  If you have suggestions on good
> > background research to read, by all means send it to the list so
> > others can get up to speed as well.
> >
> > On the atomic transaction semantics question, let's get a bit further
> > into the use-cases and framework - and then have a focused discussion.
> >  I'm not opposed to it forever or if it is necessary - just would like
> > to thoroughly analyze if it is a real requirement.
> >
> > Do others have opinions and perspective on this?
> >
> > Alia
> >
> > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> Alia:
> >>
> >> The hierarchical of interfaces (To routing system) is one of the 
> areas that requires prioritization. The prioritization must be able to 
> handle "preempt me", "after you", and "after me".
> >>
> >> It is also key to understand that irs system must handle 
> multi-interfaces struggles at the lowest layer.  You need to look at 
> the MIF WG (+/-) for some of the struggles of mobility.
> >>
> >> -----Original Message-----
> >> From: Alia Atlas [mailto:[email-masked] <mailto:[email-masked]>]
> >> Sent: Monday, July 30, 2012 6:33 PM
> >> To: Susan Hares
> >> Cc: Joel M. Halpern; [email-masked] <mailto:[email-masked]>
> >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
> >>
> >> Hi Sue,
> >>
> >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares 
> <[email-masked] <mailto:[email-masked]>> wrote:
> >>> Joel and irs-folks:
> >>>
> >>> +1 on Joel.
> >>>
> >>>  Beyond your comments, the requirement prioritization of the 
> interworking of these interfaces is not clearly delineated in this 
> work. This type of prioritization and sequencing is key to 
> multi-interfaces operation on the monitoring, configuration or 
> insertion of information into the depth.
> >>
> >> [Alia] Can you further clarify, maybe with an example, which aspect
> >> you are thinking of?  Do you mean the ability of an application to
> >> access multiple sub-interfaces?  The interaction of operations
> >> requested by differerent applications?
> >>
> >>> In addition, if you are going to do configuration with 
> roll-forward/roll-back - you need a transaction based processing.
> >>
> >> [Alia] I'm pretty sure that I avoided the word "transaction" in both
> >> drafts.  That was deliberate.  Of course, we can have a discussion
> >> about whether or not some form of transactions might be desirable.  I
> >> am concerned about their potentially heavy-weight nature.
> >>
> >>> Therefore, you've skipped even requiring the hard problems.
> >>
> >> [Alia] Can I optimistically pretend that means that the requirements
> >> we do have don't seem too hard?  For the responsiveness and throughput
> >> goals, I've put a stake in the ground to avoid transaction-based
> >> semantics.  Naturally, the hordes can run over that stake, if
> >> necessary.
> >>
> >> [Sue]: The requirements are necessary even if they are hard.
> >>
> >> [Alia] For the interaction between different layers of sub-interfaces,
> >> I've been assuming that we'll define the interactions between the
> >> layers based on how they are generally done.  For instance, perhaps we
> >> standardize the idea of preference value - and then the RIB can pick
> >> the best route based upon those preferences.  For interaction between
> >> different applications, I think there's a mixture of
> >> authorization/authentication to get right plus a good set of events
> >> that an application could register for.
> >>
> >> [Sue]: As someone who has lived with "local pref" in BGP for a long 
> time, there is a bit more to unwrap in the statement.  However, it 
> breaks down to prioritization that is pre-set by preferences.
> >>
> >> The policy issues behind the local-pref setting have been studied 
> by the BGP policy community. This is substantial good work on this 
> from the academic researchers, vendors, and operator. Griffins, 
> Rexford, Bush, Feamster, ..... and lots others are much better on the 
> theory than I am.
> >>
> >>> Is this just the -00.draft?
> >>
> >> [Alia] Certainly, I expect that we'll uncover more requirements as we
> >> go along.  As I said, some of this is initially setting parts  out of
> >> scope.
> >>
> >> ---> Scope = good.  Setting scope allows us to pick a piece of 
> this work and standardize it for interoperability.
> >>
> >> Alia
> >>
> >>> Sue
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked] 
> <mailto:[email-masked]> 
> [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Joel M. Halpern
> >>> Sent: Monday, July 30, 2012 3:15 PM
> >>> To: [email-masked] <mailto:[email-masked]>
> >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
> >>>
> >>> I am finding this document quite confusing.
> >>>
> >>> The primary confusion is that the document first says that it is about
> >>> information that can not be manipulated with existing systems, and 
> then
> >>> proceeds to give a list of use cases all of which can be manipulated
> >>> with existing systems at a suitable degree of abstraction.
> >>>
> >>> As a lesser confusion, the document says that "streaming" is 
> important,
> >>> but then describes "streaming" as "fast, interactive access."  That is
> >>> not streaming.  And depending upon what one means by interactive, 
> plenty
> >>> of systems provide "fest, interactive access." I realize the document
> >>> later goes on tot talk about speed and frequency of state 
> updates.  But
> >>> that section simply reasserts the earlier terms withotu better
> >>> description or justification.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 7/30/2012 2:08 PM, [email-masked] 
> <mailto:[email-masked]> wrote:
> >>>>
> >>>> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> >>>>
> >>>>
> >>>>      Title          : Interface to the Routing System Framework
> >>>>      Author(s)      : Alia Atlas
> >>>>                            Thomas Nadeau
> >>>>                            Dave Ward
> >>>>      Filename        : draft-ward-irs-framework-00.txt
> >>>>      Pages          : 21
> >>>>      Date            : 2012-07-30
> >>>>
> >>>> Abstract:
> >>>>    This document describes a framework for a standard, programmatic
> >>>>    interface for full-duplex, streaming state transfer in and out 
> of the
> >>>>    Internet's routing system.  It lists the information that might be
> >>>>    exchanged over the interface, and describes the uses of an 
> interface
> >>>>    to the Internet routing system.
> >>>>
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> With regard to transaction issues, we discussed this extensively when
> doing ForCES.  We concluded that the answer we needed was "yes and no".
>   That is, the protocol has mechanisms which can be used for
> transactional integrity, including integrity across interactions with
> multiple FEs.  However, the protocol does not require the CE to use
> those mechanisms.  In fact, if it does not even want explicit acks (the
> messages go over TCP), it can defer that until it gets to a good "please
> confirm" point.
> And in the efforts to use this later, having this range of options has
> been useful.
>
> Yours,
> Joel
>
> On 8/1/2012 6:51 PM, Alia Atlas wrote:
> > Sue,
> >
> > I look forward to talking with you more off-line on the policy and
> > local-pref research and issues.  If you have suggestions on good
> > background research to read, by all means send it to the list so
> > others can get up to speed as well.
> >
> > On the atomic transaction semantics question, let's get a bit further
> > into the use-cases and framework - and then have a focused discussion.
> >  I'm not opposed to it forever or if it is necessary - just would like
> > to thoroughly analyze if it is a real requirement.
> >
> > Do others have opinions and perspective on this?
> >
> > Alia
> >
> > On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> Alia:
> >>
> >> The hierarchical of interfaces (To routing system) is one of the 
> areas that requires prioritization. The prioritization must be able to 
> handle "preempt me", "after you", and "after me".
> >>
> >> It is also key to understand that irs system must handle 
> multi-interfaces struggles at the lowest layer.  You need to look at 
> the MIF WG (+/-) for some of the struggles of mobility.
> >>
> >> -----Original Message-----
> >> From: Alia Atlas [mailto:[email-masked] <mailto:[email-masked]>]
> >> Sent: Monday, July 30, 2012 6:33 PM
> >> To: Susan Hares
> >> Cc: Joel M. Halpern; [email-masked] <mailto:[email-masked]>
> >> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
> >>
> >> Hi Sue,
> >>
> >> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares 
> <[email-masked] <mailto:[email-masked]>> wrote:
> >>> Joel and irs-folks:
> >>>
> >>> +1 on Joel.
> >>>
> >>>  Beyond your comments, the requirement prioritization of the 
> interworking of these interfaces is not clearly delineated in this 
> work. This type of prioritization and sequencing is key to 
> multi-interfaces operation on the monitoring, configuration or 
> insertion of information into the depth.
> >>
> >> [Alia] Can you further clarify, maybe with an example, which aspect
> >> you are thinking of?  Do you mean the ability of an application to
> >> access multiple sub-interfaces?  The interaction of operations
> >> requested by differerent applications?
> >>
> >>> In addition, if you are going to do configuration with 
> roll-forward/roll-back - you need a transaction based processing.
> >>
> >> [Alia] I'm pretty sure that I avoided the word "transaction" in both
> >> drafts.  That was deliberate.  Of course, we can have a discussion
> >> about whether or not some form of transactions might be desirable.  I
> >> am concerned about their potentially heavy-weight nature.
> >>
> >>> Therefore, you've skipped even requiring the hard problems.
> >>
> >> [Alia] Can I optimistically pretend that means that the requirements
> >> we do have don't seem too hard?  For the responsiveness and throughput
> >> goals, I've put a stake in the ground to avoid transaction-based
> >> semantics.  Naturally, the hordes can run over that stake, if
> >> necessary.
> >>
> >> [Sue]: The requirements are necessary even if they are hard.
> >>
> >> [Alia] For the interaction between different layers of sub-interfaces,
> >> I've been assuming that we'll define the interactions between the
> >> layers based on how they are generally done.  For instance, perhaps we
> >> standardize the idea of preference value - and then the RIB can pick
> >> the best route based upon those preferences.  For interaction between
> >> different applications, I think there's a mixture of
> >> authorization/authentication to get right plus a good set of events
> >> that an application could register for.
> >>
> >> [Sue]: As someone who has lived with "local pref" in BGP for a long 
> time, there is a bit more to unwrap in the statement.  However, it 
> breaks down to prioritization that is pre-set by preferences.
> >>
> >> The policy issues behind the local-pref setting have been studied 
> by the BGP policy community. This is substantial good work on this 
> from the academic researchers, vendors, and operator. Griffins, 
> Rexford, Bush, Feamster, ..... and lots others are much better on the 
> theory than I am.
> >>
> >>> Is this just the -00.draft?
> >>
> >> [Alia] Certainly, I expect that we'll uncover more requirements as we
> >> go along.  As I said, some of this is initially setting parts  out of
> >> scope.
> >>
> >> ---> Scope = good.  Setting scope allows us to pick a piece of 
> this work and standardize it for interoperability.
> >>
> >> Alia
> >>
> >>> Sue
> >>>
> >>>
> >>>
> >>> -----Original Message-----
> >>> From: [email-masked] 
> <mailto:[email-masked]> 
> [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Joel M. Halpern
> >>> Sent: Monday, July 30, 2012 3:15 PM
> >>> To: [email-masked] <mailto:[email-masked]>
> >>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
> >>>
> >>> I am finding this document quite confusing.
> >>>
> >>> The primary confusion is that the document first says that it is about
> >>> information that can not be manipulated with existing systems, and 
> then
> >>> proceeds to give a list of use cases all of which can be manipulated
> >>> with existing systems at a suitable degree of abstraction.
> >>>
> >>> As a lesser confusion, the document says that "streaming" is 
> important,
> >>> but then describes "streaming" as "fast, interactive access."  That is
> >>> not streaming.  And depending upon what one means by interactive, 
> plenty
> >>> of systems provide "fest, interactive access." I realize the document
> >>> later goes on tot talk about speed and frequency of state 
> updates.  But
> >>> that section simply reasserts the earlier terms withotu better
> >>> description or justification.
> >>>
> >>> Yours,
> >>> Joel
> >>>
> >>> On 7/30/2012 2:08 PM, [email-masked] 
> <mailto:[email-masked]> wrote:
> >>>>
> >>>> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> >>>>
> >>>>
> >>>>        Title          : Interface to the Routing System Framework
> >>>>        Author(s)      : Alia Atlas
> >>>>                            Thomas Nadeau
> >>>>                            Dave Ward
> >>>>        Filename        : draft-ward-irs-framework-00.txt
> >>>>        Pages          : 21
> >>>>        Date            : 2012-07-30
> >>>>
> >>>> Abstract:
> >>>>      This document describes a framework for a standard, programmatic
> >>>>      interface for full-duplex, streaming state transfer in and 
> out of the
> >>>>      Internet's routing system.  It lists the information that 
> might be
> >>>>      exchanged over the interface, and describes the uses of an 
> interface
> >>>>      to the Internet routing system.
> >>>>
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >
>
> Alia:
>
> I'm going to check with a colleague who has been doing lots of model 
> work to see if he's got a better.  More later.
>
> Sue
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked] <mailto:[email-masked]>]
> Sent: Wednesday, August 01, 2012 3:41 PM
> To: Susan Hares
> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked] 
> <mailto:[email-masked]>
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Sue,
>
> In this case, I was thinking of "translating" from a "higher
> abstraction layer" to a "lower abstraction layer".
>
> Do you have a better/different term to suggest?  I agree that clarity
> of terminology is important.
>
> Alia
>
> On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > Alia:
> >
> > +1 on abstraction + filters (abstract/detail) IRS fits at the 
> routing control.
> >
> > The real question about translation is what the translation is 
> doing.  Is it translating one thing to another at the same layer of 
> abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing 
> abstraction/detail change.
> >
> > I define translation as the same layer of abstraction. Some people 
> suggest translation = abstract/detailing.  We first need a common way 
> to talk about the difference.
> >
> > Sue
> >
> > By the way --- I'm thrilled about the pace of the discussion.
> >
> >
> > -----Original Message-----
> > From: Alia Atlas [mailto:[email-masked] <mailto:[email-masked]>]
> > Sent: Monday, July 30, 2012 6:40 PM
> > To: Susan Hares
> > Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked] 
> <mailto:[email-masked]>
> > Subject: Re: [irs-discuss] IRS Problem Statement Posted
> >
> > Sue,
> >
> > I certainly agree that we want IRS to have the ability to express
> > information at different abstraction layers and filtered on request.
> >
> > There may still be a gap between the "network OS abstractions" and IRS
> > sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
> > the bottom-up control strings.
> >
> > IMHO, it's reasonable to have an entity that manages the translation.
> > For instance, one doesn't need a PCE-equiv in every application - nor
> > in every router; that might be an entity in between.
> >
> > The quantity of information is part of why explicit filtering and
> > hopefully abstraction layers should be built into the data-models.
> >
> > Alia
> >
> > On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> Nitin:
> >>
> >> Exposing some network intelligence can either be done in detail or 
> in some amount of summarization.
> >> If you are doing detail, you have bandwidth issues. If you are 
> doing summarization or opacity, you are talking about layers of 
> information.
> >>
> >> Apps need to find out what they need to get. They do not need all 
> the details - just the fact they can get from point A to Point B (or 
> for multi-cast B/C/D). They need to where they can go to date other 
> applications.  They need a match-maker for the application who 
> determine where the applications shall flow.  Now, if they are smart - 
> like people going out to eat - they pick several ways go to eat traffic.
> >>
> >> The network orchestration then serves to be the paths to the place 
> to eat.  This can either be distributed or centralized.
> >>
> >> If we have an Interface to routing, it need to have a two-layer 
> concept of exposing information.
> >>
> >> Sue Hares
> >>
> >> -----Original Message-----
> >> From: [email-masked] 
> <mailto:[email-masked]> 
> [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Nitin Bahadur
> >> Sent: Monday, July 30, 2012 3:33 PM
> >> To: James Kempf; Thomas Nadeau; [email-masked] 
> <mailto:[email-masked]>
> >> Subject: Re: [irs-discuss] IRS Problem Statement Posted
> >>
> >> Hi James,
> >>
> >> This is not about splitting control plane and forwarding plane. It 
> is about exposing network intelligence in the network elements to an 
> external controller.
> >> And it is about allowing an external controller to use that 
> information for enabling network-aware apps. And it is about allowing 
> apps to influence the
> >> network element's RIB (not the FIB directly).
> >>
> >> Streaming is essential to allow for operations at scale...and avoid 
> a request/response gated mechanism.
> >>
> >> Hope that helps.
> >>
> >> Thanks
> >> Nitin
> >>
> >> On 7/30/12 3:11 PM, "James Kempf" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >>
> >> I don't understand why streaming is specified in this draft. And I 
> don't understand why this draft isn't put in the Forces framework. 
> Forces is a framework explicitedly designed for device to controller 
> communication. Its major drawback it that it is a framework with a 
> hole in the middle, in that there are no specified devices. This draft 
> would fill that hole.
> >>
> >> I don't think it is necessary to have a problem statement for 
> router state update. Forces has already established that splitting the 
> control plane into a separate device is, in some cases, an attractive 
> design option. So I think this should be submitted to the Forces 
> working group, or, at least, recast in the Forces framework.
> >>
> >>                jak
> >>
> >>> -----Original Message-----
> >>> From: [email-masked] 
> <mailto:[email-masked]>
> >>> [mailto:[email-masked] 
> <mailto:[email-masked]>] On Behalf Of Thomas Nadeau
> >>> Sent: Monday, July 30, 2012 11:18 AM
> >>> To: [email-masked] <mailto:[email-masked]>
> >>> Subject: [irs-discuss] IRS Problem Statement Posted
> >>>
> >>>
> >>>
> >>> Please review and discuss.
> >>>
> >>> Thanks,
> >>>
> >>> Tom, Alia, Ward
> >>>
> >>>
> >>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
> >>>
> >>>
> >>> _______________________________________________
> >>> irs-discuss mailing list
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/irs-discuss
> >>>
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> >>
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
> >> _______________________________________________
> >> irs-discuss mailing list
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>
>
> > Sue: Use cases are key.  The clarity of the use cases will guide 
> us.  Please send USE cases.
>
> Here are three I just threw together. We can talk about refining these
> tomorrow, if you like... My fingers got tired before my brain did. :-)
>
> Russ
>
> =
> Optimized Exit Use Case
>
> Assume you have a network where there are two possible exit points
> towards any set of destinations. The cost of using these links varies by
> time, and the quality of the links is highly variable, but not
> necessarily related to the actual load the local network is putting on
> them (in other words, these are oversubscribed links shared with other
> parallel networks or customers with unpredictable traffic patterns).
> What you'd like to do is to use the lowest cost link until the quality
> of the link reaches a specific level, and then switch to the higher cost
> link. The point at which this link switch might occur may vary based on
> time of day, because the RTO on specific traffic levels varies by the
> time of day as well.
>
> So you have a problem with multiple variables: link quality (apparently
> random from your perspective), link cost (varies by time of day), return
> on investment (varies by time of day). Combined with this you have
> multiple exit points, and you must draw traffic from an inside network
> as efficiently as possible to the best exit point, as determined by
> these various factors.
>
> The only well defined way to resolve this problem is to feed the
> variables to an off router controller, calculate the best exit point on
> some periodic basis, and then feed this information back into the
> routing table. All solutions that can solve this problem today use route
> injection into BGP, static route injection, or some other means to
> direct traffic --difficult and error prone mechanisms. All of these
> solutions also draw traffic only along links between the edge routers
> themselves to put traffic on the best possible outbound link.
>
> With IRS, the best path could be calculated using any number of custom
> written mechanisms, and the routes injected into the right places in the
> network to effect the most efficient drawing of traffic to the best exit
> point. Changes in the network environment could quickly cause traffic to
> be shifted to alternate exit points when circumstances dictate.
>
> =
> Denial of Service
>
> FlowSpec is designed to allow an AS to push a filter upstream, with the
> ultimate goal being to block the source of DDoS and other attacks as
> close to the origin of those attacks as possible. There are some
> situations, however, where you would prefer to block an attack at all
> edges, or throughout an entire local network. For instance, you might
> want to block the forwarding of traffic within your network while you
> are pushing FlowSpec updates upstream to block the traffic closer to the
> source, or you might be dealing with an attack originating from multiple
> points within your own network.
>
> While these responses are possible with standard routing, there is a
> strong case to be made that routing information should not be mixed with
> security response information within the routing domain (within an AS).
> Mixing these two types of information can make network management more
> difficult, and slow down the repair of a network during large scale
> failures. It would be simpler to have a single controller in a network
> tied to the various attack detection mechanisms that could directly
> install the correct routing information to pull all attack traffic to a
> central location, or to simply route the traffic to a null interface.
>
> An related use is that of pulling unknown traffic through specific
> devices for analysis. A network operator may not want to drive all
> traffic through traffic analysis devices simply because of cost and
> quality of service degredation. A network operator could use IRS to
> directly modify the routing tables on devices in the path of unknown or
> possibly dangerous flows so this traffic is pulled through the correct
> monitoring and analysis devices.
>
> =
> Remote Service Routing
>
> In hub and spoke overlay networks, there is always an issue with
> balancing between the information held in the spoke routing table,
> optimal routing through the network underlying the overlay, and
> mobility. Most solutions in this space use some form of centralized
> route server that acts as a directory of all reachable destinations and
> next hops, a protocol by which spoke devices and this route server
> communicate, and caches at the remote sites.
>
> An IRS solution would use the same elements, but with a different
> control plane. Remote sites would register (or advertise through some
> standard routing protocol, such as BGP), the reachable destinations at
> each site, along with the address of the router (or other device) used
> to reach that destination. These would, as always, be stored in a route
> server (or several redundant route servers) at a central location.
>
> When a remote site sends a set of packets to the central location that
> are eventually destined to some other remote site, the central location
> can forward this traffic, but at the same time simply directly insert
> the correct routing information into the remote site's routing table. If
> the location of the destination changes, the route server can directly
> modify the routing information at the remote site as needed.
> An interesting aspect of this solution is that no new and specialized
> protocols are needed between the remote sites and the centralized route
> server(s). Normal routing protocols can be used to notify the
> centralized route server(s) of modifications in reachability
> information, and the route server(s) can respond as needed, based on
> local algorithms optimized for a particular application or network. For
> instance, short lived flows might be allowed to simply pass through the
> hub site with no reaction, while longer lived flows might warrant a
> specific route to be installed in the remote router. Algorithms can also
> be developed that would optimize traffic flow through the overlay, and
> also to remove routing entries from remote devices when they are no
> longer needed based on far greater intelligence than simple non-use for
> some period of time.
>
> =
>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked] <mailto:[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, 2 Aug 2012 10:46:27 -0700 (PDT)
From: Ning So <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] irs-discuss Digest, Vol 2, Issue 3
Reply-To: Ning So <[email-masked]>

--683666909-50796147-1343929587=:64917
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

All,
 
Is Alia's presentation loaded anywhere?  It's not on the meeting agenda page.
 
Ning

________________________________
From: "[email-masked]" <[email-masked]>
To: [email-masked] 
Sent: Thursday, August 2, 2012 1:20 AM
Subject: irs-discuss Digest, Vol 2, Issue 3

----- Forwarded Message -----

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/irs-discuss

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send irs-discuss mailing list submissions to
    [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
    https://www.ietf.org/mailman/listinfo/irs-discuss
or, via email, send a message with subject or body 'help' to
    [email-masked]

You can reach the person managing the list at
    [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of irs-discuss digest..."

Today's Topics:

  1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas)
  2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern)
  3. Re: IRS Problem Statement Posted (Susan Hares)
  4. Re: Thoughts on draft-ward-irs-framework (Russ White)
Thanks!

On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares <[email-masked]> wrote:
> Alia:
>
> I'll try to create a bibliography of things people should read.  It will be mid-next week since I'm away from my home library on the SDN topic.
>
> Sue
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2012 3:51 PM
> To: Susan Hares
> Cc: Joel M. Halpern; [email-masked]
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [email-masked]
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?  Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [email-masked]
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.  But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>      Title          : Interface to the Routing System Framework
>>>>      Author(s)      : Alia Atlas
>>>>                            Thomas Nadeau
>>>>                            Dave Ward
>>>>      Filename        : draft-ward-irs-framework-00.txt
>>>>      Pages          : 21
>>>>      Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>    This document describes a framework for a standard, programmatic
>>>>    interface for full-duplex, streaming state transfer in and out of the
>>>>    Internet's routing system.  It lists the information that might be
>>>>    exchanged over the interface, and describes the uses of an interface
>>>>    to the Internet routing system.
>>>>
>>> _______________________________________________
>>> 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

With regard to transaction issues, we discussed this extensively when 
doing ForCES.  We concluded that the answer we needed was "yes and no". 
  That is, the protocol has mechanisms which can be used for 
transactional integrity, including integrity across interactions with 
multiple FEs.  However, the protocol does not require the CE to use 
those mechanisms.  In fact, if it does not even want explicit acks (the 
messages go over TCP), it can defer that until it gets to a good "please 
confirm" point.
And in the efforts to use this later, having this range of options has 
been useful.

Yours,
Joel

On 8/1/2012 6:51 PM, Alia Atlas wrote:
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [email-masked]
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?  Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [email-masked]
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.  But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>        Title          : Interface to the Routing System Framework
>>>>        Author(s)      : Alia Atlas
>>>>                            Thomas Nadeau
>>>>                            Dave Ward
>>>>        Filename        : draft-ward-irs-framework-00.txt
>>>>        Pages          : 21
>>>>        Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>      This document describes a framework for a standard, programmatic
>>>>      interface for full-duplex, streaming state transfer in and out of the
>>>>      Internet's routing system.  It lists the information that might be
>>>>      exchanged over the interface, and describes the uses of an interface
>>>>      to the Internet routing system.
>>>>
>>> _______________________________________________
>>> 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
>

Alia:

I'm going to check with a colleague who has been doing lots of model work to see if he's got a better.  More later.

Sue 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 3:41 PM
To: Susan Hares
Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Sue,

In this case, I was thinking of "translating" from a "higher
abstraction layer" to a "lower abstraction layer".

Do you have a better/different term to suggest?  I agree that clarity
of terminology is important.

Alia

On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <[email-masked]> wrote:
> Alia:
>
> +1 on abstraction + filters (abstract/detail) IRS fits at the routing control.
>
> The real question about translation is what the translation is doing.  Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change.
>
> I define translation as the same layer of abstraction.  Some people suggest translation = abstract/detailing.  We first need a common way to talk about the difference.
>
> Sue
>
> By the way --- I'm thrilled about the pace of the discussion.
>
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Monday, July 30, 2012 6:40 PM
> To: Susan Hares
> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Sue,
>
> I certainly agree that we want IRS to have the ability to express
> information at different abstraction layers and filtered on request.
>
> There may still be a gap between the "network OS abstractions" and IRS
> sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
> the bottom-up control strings.
>
> IMHO, it's reasonable to have an entity that manages the translation.
> For instance, one doesn't need a PCE-equiv in every application - nor
> in every router; that might be an entity in between.
>
> The quantity of information is part of why explicit filtering and
> hopefully abstraction layers should be built into the data-models.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked]> wrote:
>> Nitin:
>>
>> Exposing some network intelligence can either be done in detail or in some amount of summarization.
>> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information.
>>
>> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.
>>
>> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.
>>
>> If we have an Interface to routing, it need to have a two-layer concept of exposing information.
>>
>> Sue Hares
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>> Sent: Monday, July 30, 2012 3:33 PM
>> To: James Kempf; Thomas Nadeau; [email-masked]
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Hi James,
>>
>> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
>> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
>> network element's RIB (not the FIB directly).
>>
>> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
>>
>> Hope that helps.
>>
>> Thanks
>> Nitin
>>
>> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:
>>
>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>
>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>
>>                jak
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>>> Sent: Monday, July 30, 2012 11:18 AM
>>> To: [email-masked]
>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>
>>>
>>>
>>> Please review and discuss.
>>>
>>> Thanks,
>>>
>>> Tom, Alia, Ward
>>>
>>>
>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

> Sue: Use cases are key.  The clarity of the use cases will guide us.  Please send USE cases.

Here are three I just threw together. We can talk about refining these
tomorrow, if you like... My fingers got tired before my brain did. :-)

Russ

==
Optimized Exit Use Case

Assume you have a network where there are two possible exit points
towards any set of destinations. The cost of using these links varies by
time, and the quality of the links is highly variable, but not
necessarily related to the actual load the local network is putting on
them (in other words, these are oversubscribed links shared with other
parallel networks or customers with unpredictable traffic patterns).
What you'd like to do is to use the lowest cost link until the quality
of the link reaches a specific level, and then switch to the higher cost
link. The point at which this link switch might occur may vary based on
time of day, because the RTO on specific traffic levels varies by the
time of day as well.

So you have a problem with multiple variables: link quality (apparently
random from your perspective), link cost (varies by time of day), return
on investment (varies by time of day). Combined with this you have
multiple exit points, and you must draw traffic from an inside network
as efficiently as possible to the best exit point, as determined by
these various factors.

The only well defined way to resolve this problem is to feed the
variables to an off router controller, calculate the best exit point on
some periodic basis, and then feed this information back into the
routing table. All solutions that can solve this problem today use route
injection into BGP, static route injection, or some other means to
direct traffic --difficult and error prone mechanisms. All of these
solutions also draw traffic only along links between the edge routers
themselves to put traffic on the best possible outbound link.

With IRS, the best path could be calculated using any number of custom
written mechanisms, and the routes injected into the right places in the
network to effect the most efficient drawing of traffic to the best exit
point. Changes in the network environment could quickly cause traffic to
be shifted to alternate exit points when circumstances dictate.

==
Denial of Service

FlowSpec is designed to allow an AS to push a filter upstream, with the
ultimate goal being to block the source of DDoS and other attacks as
close to the origin of those attacks as possible. There are some
situations, however, where you would prefer to block an attack at all
edges, or throughout an entire local network. For instance, you might
want to block the forwarding of traffic within your network while you
are pushing FlowSpec updates upstream to block the traffic closer to the
source, or you might be dealing with an attack originating from multiple
points within your own network.

While these responses are possible with standard routing, there is a
strong case to be made that routing information should not be mixed with
security response information within the routing domain (within an AS).
Mixing these two types of information can make network management more
difficult, and slow down the repair of a network during large scale
failures. It would be simpler to have a single controller in a network
tied to the various attack detection mechanisms that could directly
install the correct routing information to pull all attack traffic to a
central location, or to simply route the traffic to a null interface.

An related use is that of pulling unknown traffic through specific
devices for analysis. A network operator may not want to drive all
traffic through traffic analysis devices simply because of cost and
quality of service degredation. A network operator could use IRS to
directly modify the routing tables on devices in the path of unknown or
possibly dangerous flows so this traffic is pulled through the correct
monitoring and analysis devices.

==
Remote Service Routing

In hub and spoke overlay networks, there is always an issue with
balancing between the information held in the spoke routing table,
optimal routing through the network underlying the overlay, and
mobility. Most solutions in this space use some form of centralized
route server that acts as a directory of all reachable destinations and
next hops, a protocol by which spoke devices and this route server
communicate, and caches at the remote sites.

An IRS solution would use the same elements, but with a different
control plane. Remote sites would register (or advertise through some
standard routing protocol, such as BGP), the reachable destinations at
each site, along with the address of the router (or other device) used
to reach that destination. These would, as always, be stored in a route
server (or several redundant route servers) at a central location.

When a remote site sends a set of packets to the central location that
are eventually destined to some other remote site, the central location
can forward this traffic, but at the same time simply directly insert
the correct routing information into the remote site's routing table. If
the location of the destination changes, the route server can directly
modify the routing information at the remote site as needed.
An interesting aspect of this solution is that no new and specialized
protocols are needed between the remote sites and the centralized route
server(s). Normal routing protocols can be used to notify the
centralized route server(s) of modifications in reachability
information, and the route server(s) can respond as needed, based on
local algorithms optimized for a particular application or network. For
instance, short lived flows might be allowed to simply pass through the
hub site with no reaction, while longer lived flows might warrant a
specific route to be installed in the remote router. Algorithms can also
be developed that would optimize traffic flow through the overlay, and
also to remove routing entries from remote devices when they are no
longer needed based on far greater intelligence than simple non-use for
some period of time.

==

_______________________________________________
irs-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/irs-discuss
--683666909-50796147-1343929587=:64917
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><body><div style="color:#000; background-color:#fff; font-family:times new roman, new york, times, serif;font-size:12pt"><div style="RIGHT: auto"><SPAN style="RIGHT: auto">All,</SPAN></div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN>&nbsp;</div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto">Is Alia's presentation loaded anywhere?&nbsp; It's not on the meeting agenda page.<VAR id=yui-ie-cursor></VAR></SPAN></div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto"></SPAN>&nbsp;</div>
<div style="RIGHT: auto"><SPAN style="RIGHT: auto">Ning</SPAN></div>
<div><BR></div>
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
<DIV style="FONT-FAMILY: times new roman, new york, times, serif; FONT-SIZE: 12pt">
<DIV dir=ltr><FONT size=2 face=Arial>
<DIV style="BORDER-BOTTOM: #ccc 1px solid; BORDER-LEFT: #ccc 1px solid; PADDING-BOTTOM: 0px; LINE-HEIGHT: 0; MARGIN: 5px 0px; PADDING-LEFT: 0px; PADDING-RIGHT: 0px; HEIGHT: 0px; FONT-SIZE: 0px; BORDER-TOP: #ccc 1px solid; BORDER-RIGHT: #ccc 1px solid; PADDING-TOP: 0px" class=hr contentEditable=false readonly="true"></DIV><B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> "[email-masked]" &lt;[email-masked]&gt;<BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> [email-masked] <BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Thursday, August 2, 2012 1:20 AM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> irs-discuss Digest, Vol 2, Issue 3<BR></FONT></DIV><BR>----- Forwarded Message -----<BR><BR>If you have received this digest without all the individual message<BR>attachments you will need to update your digest options in your list<BR>subscription.&nbsp; To do so, go to <BR><BR><A
 href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR><BR>Click the 'Unsubscribe or edit options' button, log in, and set "Get<BR>MIME or Plain Text Digests?" to MIME.&nbsp; You can set this option<BR>globally for all the list digests you receive at this point.<BR><BR><BR><BR>Send irs-discuss mailing list submissions to<BR>&nbsp;&nbsp;&nbsp; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR>&nbsp;&nbsp;&nbsp; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR>or, via email, send a message with subject or body 'help' to<BR>&nbsp;&nbsp;&nbsp; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR><BR>You can reach
 the person managing the list at<BR>&nbsp;&nbsp;&nbsp; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of irs-discuss digest..."<BR><BR>Today's Topics:<BR><BR>&nbsp; 1. Re: I-D Action: draft-ward-irs-framework-00.txt (Alia Atlas)<BR>&nbsp; 2. Re: I-D Action: draft-ward-irs-framework-00.txt (Joel M. Halpern)<BR>&nbsp; 3. Re: IRS Problem Statement Posted (Susan Hares)<BR>&nbsp; 4. Re: Thoughts on draft-ward-irs-framework (Russ White)<BR>Thanks!<BR><BR>On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt; wrote:<BR>&gt; Alia:<BR>&gt;<BR>&gt; I'll try to create a bibliography of things people should read.&nbsp; It will be mid-next week since I'm away from my home library on the SDN
 topic.<BR>&gt;<BR>&gt; Sue<BR>&gt;<BR>&gt; -----Original Message-----<BR>&gt; From: Alia Atlas [mailto:<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>]<BR>&gt; Sent: Wednesday, August 01, 2012 3:51 PM<BR>&gt; To: Susan Hares<BR>&gt; Cc: Joel M. Halpern; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt; Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt<BR>&gt;<BR>&gt; Sue,<BR>&gt;<BR>&gt; I look forward to talking with you more off-line on the policy and<BR>&gt; local-pref research and issues.&nbsp; If you have suggestions on good<BR>&gt; background research to read, by all means send it to the list so<BR>&gt; others can get up to speed as well.<BR>&gt;<BR>&gt; On the atomic transaction semantics question, let's get a bit further<BR>&gt; into the use-cases and framework - and then have a focused discussion.<BR>&gt;&nbsp; I'm not
 opposed to it forever or if it is necessary - just would like<BR>&gt; to thoroughly analyze if it is a real requirement.<BR>&gt;<BR>&gt; Do others have opinions and perspective on this?<BR>&gt;<BR>&gt; Alia<BR>&gt;<BR>&gt; On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt; wrote:<BR>&gt;&gt; Alia:<BR>&gt;&gt;<BR>&gt;&gt; The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".<BR>&gt;&gt;<BR>&gt;&gt; It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.&nbsp; You need to look at the MIF WG (+/-) for some of the struggles of mobility.<BR>&gt;&gt;<BR>&gt;&gt; -----Original Message-----<BR>&gt;&gt; From: Alia Atlas [mailto:<A href="mailto:[email-masked]"
 ymailto="mailto:[email-masked]">[email-masked]</A>]<BR>&gt;&gt; Sent: Monday, July 30, 2012 6:33 PM<BR>&gt;&gt; To: Susan Hares<BR>&gt;&gt; Cc: Joel M. Halpern; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt; Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt<BR>&gt;&gt;<BR>&gt;&gt; Hi Sue,<BR>&gt;&gt;<BR>&gt;&gt; On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt; wrote:<BR>&gt;&gt;&gt; Joel and irs-folks:<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; +1 on Joel.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;&nbsp; Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information
 into the depth.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] Can you further clarify, maybe with an example, which aspect<BR>&gt;&gt; you are thinking of?&nbsp; Do you mean the ability of an application to<BR>&gt;&gt; access multiple sub-interfaces?&nbsp; The interaction of operations<BR>&gt;&gt; requested by differerent applications?<BR>&gt;&gt;<BR>&gt;&gt;&gt; In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] I'm pretty sure that I avoided the word "transaction" in both<BR>&gt;&gt; drafts.&nbsp; That was deliberate.&nbsp; Of course, we can have a discussion<BR>&gt;&gt; about whether or not some form of transactions might be desirable.&nbsp; I<BR>&gt;&gt; am concerned about their potentially heavy-weight nature.<BR>&gt;&gt;<BR>&gt;&gt;&gt; Therefore, you've skipped even requiring the hard problems.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] Can I optimistically pretend that
 means that the requirements<BR>&gt;&gt; we do have don't seem too hard?&nbsp; For the responsiveness and throughput<BR>&gt;&gt; goals, I've put a stake in the ground to avoid transaction-based<BR>&gt;&gt; semantics.&nbsp; Naturally, the hordes can run over that stake, if<BR>&gt;&gt; necessary.<BR>&gt;&gt;<BR>&gt;&gt; [Sue]: The requirements are necessary even if they are hard.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] For the interaction between different layers of sub-interfaces,<BR>&gt;&gt; I've been assuming that we'll define the interactions between the<BR>&gt;&gt; layers based on how they are generally done.&nbsp; For instance, perhaps we<BR>&gt;&gt; standardize the idea of preference value - and then the RIB can pick<BR>&gt;&gt; the best route based upon those preferences.&nbsp; For interaction between<BR>&gt;&gt; different applications, I think there's a mixture of<BR>&gt;&gt; authorization/authentication to get right plus a good set of events<BR>&gt;&gt;
 that an application could register for.<BR>&gt;&gt;<BR>&gt;&gt; [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.&nbsp; However, it breaks down to prioritization that is pre-set by preferences.<BR>&gt;&gt;<BR>&gt;&gt; The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.<BR>&gt;&gt;<BR>&gt;&gt;&gt; Is this just the -00.draft?<BR>&gt;&gt;<BR>&gt;&gt; [Alia] Certainly, I expect that we'll uncover more requirements as we<BR>&gt;&gt; go along.&nbsp; As I said, some of this is initially setting parts&nbsp; out of<BR>&gt;&gt; scope.<BR>&gt;&gt;<BR>&gt;&gt; ---&gt; Scope == good.&nbsp; Setting scope allows us to pick a piece of this work and standardize it for
 interoperability.<BR>&gt;&gt;<BR>&gt;&gt; Alia<BR>&gt;&gt;<BR>&gt;&gt;&gt; Sue<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; -----Original Message-----<BR>&gt;&gt;&gt; From: <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A> [mailto:<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>] On Behalf Of Joel M. Halpern<BR>&gt;&gt;&gt; Sent: Monday, July 30, 2012 3:15 PM<BR>&gt;&gt;&gt; To: <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; I am finding this document quite confusing.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; The primary confusion is that the document first says that it is about<BR>&gt;&gt;&gt; information that can not be
 manipulated with existing systems, and then<BR>&gt;&gt;&gt; proceeds to give a list of use cases all of which can be manipulated<BR>&gt;&gt;&gt; with existing systems at a suitable degree of abstraction.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; As a lesser confusion, the document says that "streaming" is important,<BR>&gt;&gt;&gt; but then describes "streaming" as "fast, interactive access."&nbsp; That is<BR>&gt;&gt;&gt; not streaming.&nbsp; And depending upon what one means by interactive, plenty<BR>&gt;&gt;&gt; of systems provide "fest, interactive access."&nbsp; I realize the document<BR>&gt;&gt;&gt; later goes on tot talk about speed and frequency of state updates.&nbsp; But<BR>&gt;&gt;&gt; that section simply reasserts the earlier terms withotu better<BR>&gt;&gt;&gt; description or justification.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; Yours,<BR>&gt;&gt;&gt; Joel<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; On 7/30/2012 2:08 PM, <A href="mailto:[email-masked]"
 ymailto="mailto:[email-masked]">[email-masked]</A> wrote:<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; A New Internet-Draft is available from the on-line Internet-Drafts directories.<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; Title&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Interface to the Routing System Framework<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; Author(s)&nbsp; &nbsp; &nbsp; : Alia Atlas<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Thomas Nadeau<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Dave Ward<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; Filename&nbsp; &nbsp; &nbsp; &nbsp; : draft-ward-irs-framework-00.txt<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; Pages&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 21<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; Date&nbsp; &nbsp; &nbsp;
 &nbsp; &nbsp; &nbsp; : 2012-07-30<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; Abstract:<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; This document describes a framework for a standard, programmatic<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; interface for full-duplex, streaming state transfer in and out of the<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; Internet's routing system.&nbsp; It lists the information that might be<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; exchanged over the interface, and describes the uses of an interface<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; to the Internet routing system.<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt; irs-discuss mailing list<BR>&gt;&gt;&gt; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR>&gt;&gt;&gt;
 _______________________________________________<BR>&gt;&gt;&gt; irs-discuss mailing list<BR>&gt;&gt;&gt; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR><BR>With regard to transaction issues, we discussed this extensively when <BR>doing ForCES.&nbsp; We concluded that the answer we needed was "yes and no". <BR>&nbsp; That is, the protocol has mechanisms which can be used for <BR>transactional integrity, including integrity across interactions with <BR>multiple FEs.&nbsp; However, the protocol does not require the CE to use <BR>those mechanisms.&nbsp; In fact, if it does not even want explicit acks (the <BR>messages go over TCP), it can defer that until it gets to a good "please <BR>confirm" point.<BR>And in the efforts to use this later, having this range
 of options has <BR>been useful.<BR><BR>Yours,<BR>Joel<BR><BR>On 8/1/2012 6:51 PM, Alia Atlas wrote:<BR>&gt; Sue,<BR>&gt;<BR>&gt; I look forward to talking with you more off-line on the policy and<BR>&gt; local-pref research and issues.&nbsp; If you have suggestions on good<BR>&gt; background research to read, by all means send it to the list so<BR>&gt; others can get up to speed as well.<BR>&gt;<BR>&gt; On the atomic transaction semantics question, let's get a bit further<BR>&gt; into the use-cases and framework - and then have a focused discussion.<BR>&gt;&nbsp; I'm not opposed to it forever or if it is necessary - just would like<BR>&gt; to thoroughly analyze if it is a real requirement.<BR>&gt;<BR>&gt; Do others have opinions and perspective on this?<BR>&gt;<BR>&gt; Alia<BR>&gt;<BR>&gt; On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt;
 wrote:<BR>&gt;&gt; Alia:<BR>&gt;&gt;<BR>&gt;&gt; The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".<BR>&gt;&gt;<BR>&gt;&gt; It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.&nbsp; You need to look at the MIF WG (+/-) for some of the struggles of mobility.<BR>&gt;&gt;<BR>&gt;&gt; -----Original Message-----<BR>&gt;&gt; From: Alia Atlas [mailto:<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>]<BR>&gt;&gt; Sent: Monday, July 30, 2012 6:33 PM<BR>&gt;&gt; To: Susan Hares<BR>&gt;&gt; Cc: Joel M. Halpern; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt; Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt<BR>&gt;&gt;<BR>&gt;&gt; Hi
 Sue,<BR>&gt;&gt;<BR>&gt;&gt; On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt; wrote:<BR>&gt;&gt;&gt; Joel and irs-folks:<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; +1 on Joel.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;&nbsp; Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] Can you further clarify, maybe with an example, which aspect<BR>&gt;&gt; you are thinking of?&nbsp; Do you mean the ability of an application to<BR>&gt;&gt; access multiple sub-interfaces?&nbsp; The interaction of operations<BR>&gt;&gt; requested by differerent applications?<BR>&gt;&gt;<BR>&gt;&gt;&gt; In addition, if you are
 going to do configuration with roll-forward/roll-back - you need a transaction based processing.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] I'm pretty sure that I avoided the word "transaction" in both<BR>&gt;&gt; drafts.&nbsp; That was deliberate.&nbsp; Of course, we can have a discussion<BR>&gt;&gt; about whether or not some form of transactions might be desirable.&nbsp; I<BR>&gt;&gt; am concerned about their potentially heavy-weight nature.<BR>&gt;&gt;<BR>&gt;&gt;&gt; Therefore, you've skipped even requiring the hard problems.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] Can I optimistically pretend that means that the requirements<BR>&gt;&gt; we do have don't seem too hard?&nbsp; For the responsiveness and throughput<BR>&gt;&gt; goals, I've put a stake in the ground to avoid transaction-based<BR>&gt;&gt; semantics.&nbsp; Naturally, the hordes can run over that stake, if<BR>&gt;&gt; necessary.<BR>&gt;&gt;<BR>&gt;&gt; [Sue]: The requirements are necessary even if they are
 hard.<BR>&gt;&gt;<BR>&gt;&gt; [Alia] For the interaction between different layers of sub-interfaces,<BR>&gt;&gt; I've been assuming that we'll define the interactions between the<BR>&gt;&gt; layers based on how they are generally done.&nbsp; For instance, perhaps we<BR>&gt;&gt; standardize the idea of preference value - and then the RIB can pick<BR>&gt;&gt; the best route based upon those preferences.&nbsp; For interaction between<BR>&gt;&gt; different applications, I think there's a mixture of<BR>&gt;&gt; authorization/authentication to get right plus a good set of events<BR>&gt;&gt; that an application could register for.<BR>&gt;&gt;<BR>&gt;&gt; [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.&nbsp; However, it breaks down to prioritization that is pre-set by preferences.<BR>&gt;&gt;<BR>&gt;&gt; The policy issues behind the local-pref setting have been studied by the BGP policy
 community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.<BR>&gt;&gt;<BR>&gt;&gt;&gt; Is this just the -00.draft?<BR>&gt;&gt;<BR>&gt;&gt; [Alia] Certainly, I expect that we'll uncover more requirements as we<BR>&gt;&gt; go along.&nbsp; As I said, some of this is initially setting parts&nbsp; out of<BR>&gt;&gt; scope.<BR>&gt;&gt;<BR>&gt;&gt; ---&gt; Scope == good.&nbsp; Setting scope allows us to pick a piece of this work and standardize it for interoperability.<BR>&gt;&gt;<BR>&gt;&gt; Alia<BR>&gt;&gt;<BR>&gt;&gt;&gt; Sue<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; -----Original Message-----<BR>&gt;&gt;&gt; From: <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A> [mailto:<A href="mailto:[email-masked]"
 ymailto="mailto:[email-masked]">[email-masked]</A>] On Behalf Of Joel M. Halpern<BR>&gt;&gt;&gt; Sent: Monday, July 30, 2012 3:15 PM<BR>&gt;&gt;&gt; To: <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; I am finding this document quite confusing.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; The primary confusion is that the document first says that it is about<BR>&gt;&gt;&gt; information that can not be manipulated with existing systems, and then<BR>&gt;&gt;&gt; proceeds to give a list of use cases all of which can be manipulated<BR>&gt;&gt;&gt; with existing systems at a suitable degree of abstraction.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; As a lesser confusion, the document says that "streaming" is important,<BR>&gt;&gt;&gt; but then describes "streaming" as "fast,
 interactive access."&nbsp; That is<BR>&gt;&gt;&gt; not streaming.&nbsp; And depending upon what one means by interactive, plenty<BR>&gt;&gt;&gt; of systems provide "fest, interactive access."&nbsp; I realize the document<BR>&gt;&gt;&gt; later goes on tot talk about speed and frequency of state updates.&nbsp; But<BR>&gt;&gt;&gt; that section simply reasserts the earlier terms withotu better<BR>&gt;&gt;&gt; description or justification.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; Yours,<BR>&gt;&gt;&gt; Joel<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; On 7/30/2012 2:08 PM, <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A> wrote:<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; A New Internet-Draft is available from the on-line Internet-Drafts directories.<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; Title&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : Interface to the Routing System
 Framework<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; Author(s)&nbsp; &nbsp; &nbsp; : Alia Atlas<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Thomas Nadeau<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Dave Ward<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; Filename&nbsp; &nbsp; &nbsp; &nbsp; : draft-ward-irs-framework-00.txt<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; Pages&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 21<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; Date&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; : 2012-07-30<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt;&gt; Abstract:<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; This document describes a framework for a standard, programmatic<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; interface for full-duplex, streaming state transfer in and out of the<BR>&gt;&gt;&gt;&gt;&nbsp;
 &nbsp; &nbsp; Internet's routing system.&nbsp; It lists the information that might be<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; exchanged over the interface, and describes the uses of an interface<BR>&gt;&gt;&gt;&gt;&nbsp; &nbsp; &nbsp; to the Internet routing system.<BR>&gt;&gt;&gt;&gt;<BR>&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt; irs-discuss mailing list<BR>&gt;&gt;&gt; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR>&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt; irs-discuss mailing list<BR>&gt;&gt;&gt; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss"
 target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR>&gt;<BR><BR>Alia:<BR><BR>I'm going to check with a colleague who has been doing lots of model work to see if he's got a better.&nbsp; More later.<BR><BR>Sue <BR><BR>-----Original Message-----<BR>From: Alia Atlas [mailto:<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>] <BR>Sent: Wednesday, August 01, 2012 3:41 PM<BR>To: Susan Hares<BR>Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>Subject: Re: [irs-discuss] IRS Problem Statement Posted<BR><BR>Sue,<BR><BR>In this case, I was thinking of "translating" from a "higher<BR>abstraction layer" to a "lower abstraction layer".<BR><BR>Do you have a better/different term to suggest?&nbsp; I agree that clarity<BR>of terminology is important.<BR><BR>Alia<BR><BR>On Wed, Aug 1, 2012 at 2:03 PM, Susan
 Hares &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt; wrote:<BR>&gt; Alia:<BR>&gt;<BR>&gt; +1 on abstraction + filters (abstract/detail) IRS fits at the routing control.<BR>&gt;<BR>&gt; The real question about translation is what the translation is doing.&nbsp; Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change.<BR>&gt;<BR>&gt; I define translation as the same layer of abstraction.&nbsp; Some people suggest translation = abstract/detailing.&nbsp; We first need a common way to talk about the difference.<BR>&gt;<BR>&gt; Sue<BR>&gt;<BR>&gt; By the way --- I'm thrilled about the pace of the discussion.<BR>&gt;<BR>&gt;<BR>&gt; -----Original Message-----<BR>&gt; From: Alia Atlas [mailto:<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>]<BR>&gt; Sent:
 Monday, July 30, 2012 6:40 PM<BR>&gt; To: Susan Hares<BR>&gt; Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt; Subject: Re: [irs-discuss] IRS Problem Statement Posted<BR>&gt;<BR>&gt; Sue,<BR>&gt;<BR>&gt; I certainly agree that we want IRS to have the ability to express<BR>&gt; information at different abstraction layers and filtered on request.<BR>&gt;<BR>&gt; There may still be a gap between the "network OS abstractions" and IRS<BR>&gt; sub-interfaces; I'd be surprised if there weren't.&nbsp; IRS is to provide<BR>&gt; the bottom-up control strings.<BR>&gt;<BR>&gt; IMHO, it's reasonable to have an entity that manages the translation.<BR>&gt; For instance, one doesn't need a PCE-equiv in every application - nor<BR>&gt; in every router; that might be an entity in between.<BR>&gt;<BR>&gt; The quantity of information is part of why explicit filtering
 and<BR>&gt; hopefully abstraction layers should be built into the data-models.<BR>&gt;<BR>&gt; Alia<BR>&gt;<BR>&gt; On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt; wrote:<BR>&gt;&gt; Nitin:<BR>&gt;&gt;<BR>&gt;&gt; Exposing some network intelligence can either be done in detail or in some amount of summarization.<BR>&gt;&gt; If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information.<BR>&gt;&gt;<BR>&gt;&gt; Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.&nbsp; They need a match-maker for the application who determine where the applications shall flow.&nbsp; Now, if they are smart - like people going
 out to eat - they pick several ways go to eat traffic.<BR>&gt;&gt;<BR>&gt;&gt; The network orchestration then serves to be the paths to the place to eat.&nbsp; This can either be distributed or centralized.<BR>&gt;&gt;<BR>&gt;&gt; If we have an Interface to routing, it need to have a two-layer concept of exposing information.<BR>&gt;&gt;<BR>&gt;&gt; Sue Hares<BR>&gt;&gt;<BR>&gt;&gt; -----Original Message-----<BR>&gt;&gt; From: <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A> [mailto:<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>] On Behalf Of Nitin Bahadur<BR>&gt;&gt; Sent: Monday, July 30, 2012 3:33 PM<BR>&gt;&gt; To: James Kempf; Thomas Nadeau; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt; Subject: Re: [irs-discuss] IRS Problem
 Statement Posted<BR>&gt;&gt;<BR>&gt;&gt; Hi James,<BR>&gt;&gt;<BR>&gt;&gt; This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.<BR>&gt;&gt; And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the<BR>&gt;&gt; network element's RIB (not the FIB directly).<BR>&gt;&gt;<BR>&gt;&gt; Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.<BR>&gt;&gt;<BR>&gt;&gt; Hope that helps.<BR>&gt;&gt;<BR>&gt;&gt; Thanks<BR>&gt;&gt; Nitin<BR>&gt;&gt;<BR>&gt;&gt; On 7/30/12 3:11 PM, "James Kempf" &lt;<A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>&gt; wrote:<BR>&gt;&gt;<BR>&gt;&gt; I don't understand why streaming is specified in this draft. And I don't understand
 why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.<BR>&gt;&gt;<BR>&gt;&gt; I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.<BR>&gt;&gt;<BR>&gt;&gt;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; jak<BR>&gt;&gt;<BR>&gt;&gt;&gt; -----Original Message-----<BR>&gt;&gt;&gt; From: <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; [mailto:<A
 href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A>] On Behalf Of Thomas Nadeau<BR>&gt;&gt;&gt; Sent: Monday, July 30, 2012 11:18 AM<BR>&gt;&gt;&gt; To: <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; Subject: [irs-discuss] IRS Problem Statement Posted<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; Please review and discuss.<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; Thanks,<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; Tom, Alia, Ward<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; <A href="http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt" target=_blank>http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt</A><BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt;<BR>&gt;&gt;&gt; _______________________________________________<BR>&gt;&gt;&gt; irs-discuss mailing list<BR>&gt;&gt;&gt; <A href="mailto:[email-masked]"
 ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR>&gt;&gt;&gt;<BR>&gt;&gt; _______________________________________________<BR>&gt;&gt; irs-discuss mailing list<BR>&gt;&gt; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR>&gt;&gt;<BR>&gt;&gt; _______________________________________________<BR>&gt;&gt; irs-discuss mailing list<BR>&gt;&gt; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR>&gt;&gt;
 _______________________________________________<BR>&gt;&gt; irs-discuss mailing list<BR>&gt;&gt; <A href="mailto:[email-masked]" ymailto="mailto:[email-masked]">[email-masked]</A><BR>&gt;&gt; <A href="https://www.ietf.org/mailman/listinfo/irs-discuss" target=_blank>https://www.ietf.org/mailman/listinfo/irs-discuss</A><BR><BR><BR>&gt; Sue: Use cases are key.&nbsp; The clarity of the use cases will guide us.&nbsp; Please send USE cases.<BR><BR>Here are three I just threw together. We can talk about refining these<BR>tomorrow, if you like... My fingers got tired before my brain did. :-)<BR><BR>Russ<BR><BR>==<BR>Optimized Exit Use Case<BR><BR>Assume you have a network where there are two possible exit points<BR>towards any set of destinations. The cost of using these links varies by<BR>time, and the quality of the links is highly variable, but not<BR>necessarily related to the actual load the local network is putting on<BR>them (in other
 words, these are oversubscribed links shared with other<BR>parallel networks or customers with unpredictable traffic patterns).<BR>What you'd like to do is to use the lowest cost link until the quality<BR>of the link reaches a specific level, and then switch to the higher cost<BR>link. The point at which this link switch might occur may vary based on<BR>time of day, because the RTO on specific traffic levels varies by the<BR>time of day as well.<BR><BR>So you have a problem with multiple variables: link quality (apparently<BR>random from your perspective), link cost (varies by time of day), return<BR>on investment (varies by time of day). Combined with this you have<BR>multiple exit points, and you must draw traffic from an inside network<BR>as efficiently as possible to the best exit point, as determined by<BR>these various factors.<BR><BR>The only well defined way to resolve this problem is to feed the<BR>variables to an off router controller,
 calculate the best exit point on<BR>some periodic basis, and then feed this information back into the<BR>routing table. All solutions that can solve this problem today use route<BR>injection into BGP, static route injection, or some other means to<BR>direct traffic --difficult and error prone mechanisms. All of these<BR>solutions also draw traffic only along links between the edge routers<BR>themselves to put traffic on the best possible outbound link.<BR><BR>With IRS, the best path could be calculated using any number of custom<BR>written mechanisms, and the routes injected into the right places in the<BR>network to effect the most efficient drawing of traffic to the best exit<BR>point. Changes in the network environment could quickly cause traffic to<BR>be shifted to alternate exit points when circumstances dictate.<BR><BR>==<BR>Denial of Service<BR><BR>FlowSpec is designed to allow an AS to push a filter upstream, with the<BR>ultimate goal being to
 block the source of DDoS and other attacks as<BR>close to the origin of those attacks as possible. There are some<BR>situations, however, where you would prefer to block an attack at all<BR>edges, or throughout an entire local network. For instance, you might<BR>want to block the forwarding of traffic within your network while you<BR>are pushing FlowSpec updates upstream to block the traffic closer to the<BR>source, or you might be dealing with an attack originating from multiple<BR>points within your own network.<BR><BR>While these responses are possible with standard routing, there is a<BR>strong case to be made that routing information should not be mixed with<BR>security response information within the routing domain (within an AS).<BR>Mixing these two types of information can make network management more<BR>difficult, and slow down the repair of a network during large scale<BR>failures. It would be simpler to have a single controller in a
 network<BR>tied to the various attack detection mechanisms that could directly<BR>install the correct routing information to pull all attack traffic to a<BR>central location, or to simply route the traffic to a null interface.<BR><BR>An related use is that of pulling unknown traffic through specific<BR>devices for analysis. A network operator may not want to drive all<BR>traffic through traffic analysis devices simply because of cost and<BR>quality of service degredation. A network operator could use IRS to<BR>directly modify the routing tables on devices in the path of unknown or<BR>possibly dangerous flows so this traffic is pulled through the correct<BR>monitoring and analysis devices.<BR><BR>==<BR>Remote Service Routing<BR><BR>In hub and spoke overlay networks, there is always an issue with<BR>balancing between the information held in the spoke routing table,<BR>optimal routing through the network underlying the overlay, and<BR>mobility. Most
 solutions in this space use some form of centralized<BR>route server that acts as a directory of all reachable destinations and<BR>next hops, a protocol by which spoke devices and this route server<BR>communicate, and caches at the remote sites.<BR><BR>An IRS solution would use the same elements, but with a different<BR>control plane. Remote sites would register (or advertise through some<BR>standard routing protocol, such as BGP), the reachable destinations at<BR>each site, along with the address of the router (or other device) used<BR>to reach that destination. These would, as always, be stored in a route<BR>server (or several redundant route servers) at a central location.<BR><BR>When a remote site sends a set of packets to the central location that<BR>are eventually destined to some other remote site, the central location<BR>can forward this traffic, but at the same time simply directly insert<BR>the correct routing information into the remote
 site's routing table. If<BR>the location of the destination changes, the route server can directly<BR>modify the routing information at the remote site as needed.<BR>An interesting aspect of this solution is that no new and specialized<BR>protocols are needed between the remote sites and the centralized route<BR>server(s). Normal routing protocols can be used to notify the<BR>centralized route server(s) of modifications in reachability<BR>information, and the route server(s) can respond as needed, based on<BR>local algorithms optimized for a particular application or network. For<BR>instance, short lived flows might be allowed to simply pass through the<BR>hub site with no reaction, while longer lived flows might warrant a<BR>specific route to be installed in the remote router. Algorithms can also<BR>be developed that would optimize traffic flow through the overlay, and<BR>also to remove routing entries from remote devices when they are no<BR>longer
 needed based on far greater intelligence than simple non-use for<BR>some period of time.<BR><BR>==<BR><BR><BR>_______________________________________________<BR>irs-discuss mailing list<BR><A href="mailto:[email-masked]" ymailto="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><BR><BR></DIV></DIV></div></body></html>
--683666909-50796147-1343929587=:64917--

Date: Thu, 02 Aug 2012 19:45:48 +0200
From: Robert Raszuk <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: [email-masked]
Subject: [irs-discuss] Clarification questions ...
Reply-To: [email-masked]

Q1:

I have seen a framework slide showing IRS Agent withing the router.

I would like to clarify if you are going to have such IRS Agent in each 
router participating in given (maybe new) service in the AS ? How many 
IRS clients your envision ?

Is the model of 1000s of IRS agents talking to 10s of IRS clients as 
example ?

Q2:

Is data currently distributed by routing protocols explicitly prohibited 
to be also distributed by IRS overlay and send to the routers by TBD IRS 
channel ?

Thx a lot !
R.

From: Thomas Nadeau <[email-masked]>
Date: Thu, 2 Aug 2012 09:24:43 -0700
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework

	Russ,

	These are very cool. Thanks for posting them.  It would be great to get these into draft form and online. 8)

	--Tom

On Aug 1, 2012:10:20 PM, at 10:20 PM, Russ White <[email-masked]> wrote:

> 
>> Sue: Use cases are key.  The clarity of the use cases will guide us.  Please send USE cases.
> 
> Here are three I just threw together. We can talk about refining these
> tomorrow, if you like... My fingers got tired before my brain did. :-)
> 
> Russ
> 
> ==
> Optimized Exit Use Case
> 
> Assume you have a network where there are two possible exit points
> towards any set of destinations. The cost of using these links varies by
> time, and the quality of the links is highly variable, but not
> necessarily related to the actual load the local network is putting on
> them (in other words, these are oversubscribed links shared with other
> parallel networks or customers with unpredictable traffic patterns).
> What you'd like to do is to use the lowest cost link until the quality
> of the link reaches a specific level, and then switch to the higher cost
> link. The point at which this link switch might occur may vary based on
> time of day, because the RTO on specific traffic levels varies by the
> time of day as well.
> 
> So you have a problem with multiple variables: link quality (apparently
> random from your perspective), link cost (varies by time of day), return
> on investment (varies by time of day). Combined with this you have
> multiple exit points, and you must draw traffic from an inside network
> as efficiently as possible to the best exit point, as determined by
> these various factors.
> 
> The only well defined way to resolve this problem is to feed the
> variables to an off router controller, calculate the best exit point on
> some periodic basis, and then feed this information back into the
> routing table. All solutions that can solve this problem today use route
> injection into BGP, static route injection, or some other means to
> direct traffic --difficult and error prone mechanisms. All of these
> solutions also draw traffic only along links between the edge routers
> themselves to put traffic on the best possible outbound link.
> 
> With IRS, the best path could be calculated using any number of custom
> written mechanisms, and the routes injected into the right places in the
> network to effect the most efficient drawing of traffic to the best exit
> point. Changes in the network environment could quickly cause traffic to
> be shifted to alternate exit points when circumstances dictate.
> 
> ==
> Denial of Service
> 
> FlowSpec is designed to allow an AS to push a filter upstream, with the
> ultimate goal being to block the source of DDoS and other attacks as
> close to the origin of those attacks as possible. There are some
> situations, however, where you would prefer to block an attack at all
> edges, or throughout an entire local network. For instance, you might
> want to block the forwarding of traffic within your network while you
> are pushing FlowSpec updates upstream to block the traffic closer to the
> source, or you might be dealing with an attack originating from multiple
> points within your own network.
> 
> While these responses are possible with standard routing, there is a
> strong case to be made that routing information should not be mixed with
> security response information within the routing domain (within an AS).
> Mixing these two types of information can make network management more
> difficult, and slow down the repair of a network during large scale
> failures. It would be simpler to have a single controller in a network
> tied to the various attack detection mechanisms that could directly
> install the correct routing information to pull all attack traffic to a
> central location, or to simply route the traffic to a null interface.
> 
> An related use is that of pulling unknown traffic through specific
> devices for analysis. A network operator may not want to drive all
> traffic through traffic analysis devices simply because of cost and
> quality of service degredation. A network operator could use IRS to
> directly modify the routing tables on devices in the path of unknown or
> possibly dangerous flows so this traffic is pulled through the correct
> monitoring and analysis devices.
> 
> ==
> Remote Service Routing
> 
> In hub and spoke overlay networks, there is always an issue with
> balancing between the information held in the spoke routing table,
> optimal routing through the network underlying the overlay, and
> mobility. Most solutions in this space use some form of centralized
> route server that acts as a directory of all reachable destinations and
> next hops, a protocol by which spoke devices and this route server
> communicate, and caches at the remote sites.
> 
> An IRS solution would use the same elements, but with a different
> control plane. Remote sites would register (or advertise through some
> standard routing protocol, such as BGP), the reachable destinations at
> each site, along with the address of the router (or other device) used
> to reach that destination. These would, as always, be stored in a route
> server (or several redundant route servers) at a central location.
> 
> When a remote site sends a set of packets to the central location that
> are eventually destined to some other remote site, the central location
> can forward this traffic, but at the same time simply directly insert
> the correct routing information into the remote site's routing table. If
> the location of the destination changes, the route server can directly
> modify the routing information at the remote site as needed.
> An interesting aspect of this solution is that no new and specialized
> protocols are needed between the remote sites and the centralized route
> server(s). Normal routing protocols can be used to notify the
> centralized route server(s) of modifications in reachability
> information, and the route server(s) can respond as needed, based on
> local algorithms optimized for a particular application or network. For
> instance, short lived flows might be allowed to simply pass through the
> hub site with no reaction, while longer lived flows might warrant a
> specific route to be installed in the remote router. Algorithms can also
> be developed that would optimize traffic flow through the overlay, and
> also to remove routing entries from remote devices when they are no
> longer needed based on far greater intelligence than simple non-use for
> some period of time.
> 
> ==
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

Date: Thu, 2 Aug 2012 01:30:54 -0400
From: Alia Atlas <[email-masked]>
To: Russ White <[email-masked]>
Cc: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework

K - so the idea of the IRS sub-interface to the RIB being semantically
similar to another routing process sounds like an initially useful way
of describing it - but we're going to want to qualify out what that
means in terms of interactions and into the appropriate description &
models.

Alia

On Thu, Aug 2, 2012 at 1:26 AM, Russ White <[email-masked]> wrote:
>
>> ----> [Russ]: +1 - This Offboard controller processing aligns with the ONF view of SDN.  And it has been done in practice for 10+ years. However as you know, the timing between the calculation and download to HW is important.
>
> If we just insert the information into "yet another process" parallel
> with the already existing routing processes on the hardware, I think we
> shunt aside the problems with insertion speed, etc. Routes installed in
> this "off board interface routing process" would be handled just like
> routes learned through other sources. Any improvements in the speed of
> route insertion from, say, OSPF running on the box would be reflected in
> speed improvements for IRS. IMHO, this is a huge win overall.
>
>> One
>> difference, though, is the idea that different static routes installed
>> by IRS may want to have different preference values.
>
> All the implementations I've worked with have the ability to install
> routes from a single process with different preferences. If no
> preference is specifically stated, the process' preference is used.
> Specific per route preferences override these, though --see, for
> instance, the EIGRP distance command in IOS. I suspect all
> implementations have the ability to handle this sort of thing in the API
> between each routing process and the RIB, but it's just not used a lot.
>
> :-)
>
> Russ
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Thu, 02 Aug 2012 01:26:06 -0400
From: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework

> ----> [Russ]: +1 - This Offboard controller processing aligns with the ONF view of SDN.  And it has been done in practice for 10+ years. However as you know, the timing between the calculation and download to HW is important. 

If we just insert the information into "yet another process" parallel
with the already existing routing processes on the hardware, I think we
shunt aside the problems with insertion speed, etc. Routes installed in
this "off board interface routing process" would be handled just like
routes learned through other sources. Any improvements in the speed of
route insertion from, say, OSPF running on the box would be reflected in
speed improvements for IRS. IMHO, this is a huge win overall.

> One
> difference, though, is the idea that different static routes installed
> by IRS may want to have different preference values.

All the implementations I've worked with have the ability to install
routes from a single process with different preferences. If no
preference is specifically stated, the process' preference is used.
Specific per route preferences override these, though --see, for
instance, the EIGRP distance command in IOS. I suspect all
implementations have the ability to handle this sort of thing in the API
between each routing process and the RIB, but it's just not used a lot.

:-)

Russ

Date: Thu, 02 Aug 2012 01:20:34 -0400
From: Russ White <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework

> Sue: Use cases are key.  The clarity of the use cases will guide us.  Please send USE cases.

Here are three I just threw together. We can talk about refining these
tomorrow, if you like... My fingers got tired before my brain did. :-)

Russ

=
Optimized Exit Use Case

Assume you have a network where there are two possible exit points
towards any set of destinations. The cost of using these links varies by
time, and the quality of the links is highly variable, but not
necessarily related to the actual load the local network is putting on
them (in other words, these are oversubscribed links shared with other
parallel networks or customers with unpredictable traffic patterns).
What you'd like to do is to use the lowest cost link until the quality
of the link reaches a specific level, and then switch to the higher cost
link. The point at which this link switch might occur may vary based on
time of day, because the RTO on specific traffic levels varies by the
time of day as well.

So you have a problem with multiple variables: link quality (apparently
random from your perspective), link cost (varies by time of day), return
on investment (varies by time of day). Combined with this you have
multiple exit points, and you must draw traffic from an inside network
as efficiently as possible to the best exit point, as determined by
these various factors.

The only well defined way to resolve this problem is to feed the
variables to an off router controller, calculate the best exit point on
some periodic basis, and then feed this information back into the
routing table. All solutions that can solve this problem today use route
injection into BGP, static route injection, or some other means to
direct traffic --difficult and error prone mechanisms. All of these
solutions also draw traffic only along links between the edge routers
themselves to put traffic on the best possible outbound link.

With IRS, the best path could be calculated using any number of custom
written mechanisms, and the routes injected into the right places in the
network to effect the most efficient drawing of traffic to the best exit
point. Changes in the network environment could quickly cause traffic to
be shifted to alternate exit points when circumstances dictate.

=
Denial of Service

FlowSpec is designed to allow an AS to push a filter upstream, with the
ultimate goal being to block the source of DDoS and other attacks as
close to the origin of those attacks as possible. There are some
situations, however, where you would prefer to block an attack at all
edges, or throughout an entire local network. For instance, you might
want to block the forwarding of traffic within your network while you
are pushing FlowSpec updates upstream to block the traffic closer to the
source, or you might be dealing with an attack originating from multiple
points within your own network.

While these responses are possible with standard routing, there is a
strong case to be made that routing information should not be mixed with
security response information within the routing domain (within an AS).
Mixing these two types of information can make network management more
difficult, and slow down the repair of a network during large scale
failures. It would be simpler to have a single controller in a network
tied to the various attack detection mechanisms that could directly
install the correct routing information to pull all attack traffic to a
central location, or to simply route the traffic to a null interface.

An related use is that of pulling unknown traffic through specific
devices for analysis. A network operator may not want to drive all
traffic through traffic analysis devices simply because of cost and
quality of service degredation. A network operator could use IRS to
directly modify the routing tables on devices in the path of unknown or
possibly dangerous flows so this traffic is pulled through the correct
monitoring and analysis devices.

=
Remote Service Routing

In hub and spoke overlay networks, there is always an issue with
balancing between the information held in the spoke routing table,
optimal routing through the network underlying the overlay, and
mobility. Most solutions in this space use some form of centralized
route server that acts as a directory of all reachable destinations and
next hops, a protocol by which spoke devices and this route server
communicate, and caches at the remote sites.

An IRS solution would use the same elements, but with a different
control plane. Remote sites would register (or advertise through some
standard routing protocol, such as BGP), the reachable destinations at
each site, along with the address of the router (or other device) used
to reach that destination. These would, as always, be stored in a route
server (or several redundant route servers) at a central location.

When a remote site sends a set of packets to the central location that
are eventually destined to some other remote site, the central location
can forward this traffic, but at the same time simply directly insert
the correct routing information into the remote site's routing table. If
the location of the destination changes, the route server can directly
modify the routing information at the remote site as needed.
An interesting aspect of this solution is that no new and specialized
protocols are needed between the remote sites and the centralized route
server(s). Normal routing protocols can be used to notify the
centralized route server(s) of modifications in reachability
information, and the route server(s) can respond as needed, based on
local algorithms optimized for a particular application or network. For
instance, short lived flows might be allowed to simply pass through the
hub site with no reaction, while longer lived flows might warrant a
specific route to be installed in the remote router. Algorithms can also
be developed that would optimize traffic flow through the overlay, and
also to remove routing entries from remote devices when they are no
longer needed based on far greater intelligence than simple non-use for
some period of time.

=

From: Susan Hares <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 1 Aug 2012 23:20:55 +0000
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Alia:

I'm going to check with a colleague who has been doing lots of model work to see if he's got a better.  More later.

Sue 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 3:41 PM
To: Susan Hares
Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Sue,

In this case, I was thinking of "translating" from a "higher
abstraction layer" to a "lower abstraction layer".

Do you have a better/different term to suggest?  I agree that clarity
of terminology is important.

Alia

On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <[email-masked]> wrote:
> Alia:
>
> +1 on abstraction + filters (abstract/detail) IRS fits at the routing control.
>
> The real question about translation is what the translation is doing.  Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change.
>
> I define translation as the same layer of abstraction.  Some people suggest translation = abstract/detailing.  We first need a common way to talk about the difference.
>
> Sue
>
> By the way --- I'm thrilled about the pace of the discussion.
>
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Monday, July 30, 2012 6:40 PM
> To: Susan Hares
> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Sue,
>
> I certainly agree that we want IRS to have the ability to express
> information at different abstraction layers and filtered on request.
>
> There may still be a gap between the "network OS abstractions" and IRS
> sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
> the bottom-up control strings.
>
> IMHO, it's reasonable to have an entity that manages the translation.
> For instance, one doesn't need a PCE-equiv in every application - nor
> in every router; that might be an entity in between.
>
> The quantity of information is part of why explicit filtering and
> hopefully abstraction layers should be built into the data-models.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked]> wrote:
>> Nitin:
>>
>> Exposing some network intelligence can either be done in detail or in some amount of summarization.
>> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information.
>>
>> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.
>>
>> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.
>>
>> If we have an Interface to routing, it need to have a two-layer concept of exposing information.
>>
>> Sue Hares
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>> Sent: Monday, July 30, 2012 3:33 PM
>> To: James Kempf; Thomas Nadeau; [email-masked]
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Hi James,
>>
>> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
>> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
>> network element's RIB (not the FIB directly).
>>
>> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
>>
>> Hope that helps.
>>
>> Thanks
>> Nitin
>>
>> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:
>>
>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>
>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>
>>                 jak
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>>> Sent: Monday, July 30, 2012 11:18 AM
>>> To: [email-masked]
>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>
>>>
>>>
>>> Please review and discuss.
>>>
>>> Thanks,
>>>
>>> Tom, Alia, Ward
>>>
>>>
>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Wed, 01 Aug 2012 19:01:07 -0400
From: "Joel M. Halpern" <[email-masked]>
To: Alia Atlas <[email-masked]>
Cc: Susan Hares <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

With regard to transaction issues, we discussed this extensively when 
doing ForCES.  We concluded that the answer we needed was "yes and no". 
  That is, the protocol has mechanisms which can be used for 
transactional integrity, including integrity across interactions with 
multiple FEs.  However, the protocol does not require the CE to use 
those mechanisms.  In fact, if it does not even want explicit acks (the 
messages go over TCP), it can defer that until it gets to a good "please 
confirm" point.
And in the efforts to use this later, having this range of options has 
been useful.

Yours,
Joel

On 8/1/2012 6:51 PM, Alia Atlas wrote:
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>   I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [email-masked]
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>   Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?   Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope = good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [email-masked]
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.   But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>        Title           : Interface to the Routing System Framework
>>>>        Author(s)       : Alia Atlas
>>>>                             Thomas Nadeau
>>>>                             Dave Ward
>>>>        Filename        : draft-ward-irs-framework-00.txt
>>>>        Pages           : 21
>>>>        Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>      This document describes a framework for a standard, programmatic
>>>>      interface for full-duplex, streaming state transfer in and out of the
>>>>      Internet's routing system.  It lists the information that might be
>>>>      exchanged over the interface, and describes the uses of an interface
>>>>      to the Internet routing system.
>>>>
>>> _______________________________________________
>>> 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: Wed, 1 Aug 2012 18:58:54 -0400
From: Alia Atlas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Thanks!

On Wed, Aug 1, 2012 at 6:54 PM, Susan Hares <[email-masked]> wrote:
> Alia:
>
> I'll try to create a bibliography of things people should read.  It will be mid-next week since I'm away from my home library on the SDN topic.
>
> Sue
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Wednesday, August 01, 2012 3:51 PM
> To: Susan Hares
> Cc: Joel M. Halpern; [email-masked]
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> Sue,
>
> I look forward to talking with you more off-line on the policy and
> local-pref research and issues.  If you have suggestions on good
> background research to read, by all means send it to the list so
> others can get up to speed as well.
>
> On the atomic transaction semantics question, let's get a bit further
> into the use-cases and framework - and then have a focused discussion.
>  I'm not opposed to it forever or if it is necessary - just would like
> to thoroughly analyze if it is a real requirement.
>
> Do others have opinions and perspective on this?
>
> Alia
>
> On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]> wrote:
>> Alia:
>>
>> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>>
>> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[email-masked]]
>> Sent: Monday, July 30, 2012 6:33 PM
>> To: Susan Hares
>> Cc: Joel M. Halpern; [email-masked]
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> Hi Sue,
>>
>> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote:
>>> Joel and irs-folks:
>>>
>>> +1 on Joel.
>>>
>>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>>
>> [Alia] Can you further clarify, maybe with an example, which aspect
>> you are thinking of?   Do you mean the ability of an application to
>> access multiple sub-interfaces?  The interaction of operations
>> requested by differerent applications?
>>
>>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>>
>> [Alia] I'm pretty sure that I avoided the word "transaction" in both
>> drafts.  That was deliberate.  Of course, we can have a discussion
>> about whether or not some form of transactions might be desirable.  I
>> am concerned about their potentially heavy-weight nature.
>>
>>> Therefore, you've skipped even requiring the hard problems.
>>
>> [Alia] Can I optimistically pretend that means that the requirements
>> we do have don't seem too hard?  For the responsiveness and throughput
>> goals, I've put a stake in the ground to avoid transaction-based
>> semantics.  Naturally, the hordes can run over that stake, if
>> necessary.
>>
>> [Sue]: The requirements are necessary even if they are hard.
>>
>> [Alia] For the interaction between different layers of sub-interfaces,
>> I've been assuming that we'll define the interactions between the
>> layers based on how they are generally done.  For instance, perhaps we
>> standardize the idea of preference value - and then the RIB can pick
>> the best route based upon those preferences.  For interaction between
>> different applications, I think there's a mixture of
>> authorization/authentication to get right plus a good set of events
>> that an application could register for.
>>
>> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>>
>> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>>
>>> Is this just the -00.draft?
>>
>> [Alia] Certainly, I expect that we'll uncover more requirements as we
>> go along.  As I said, some of this is initially setting parts  out of
>> scope.
>>
>> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>>
>> Alia
>>
>>> Sue
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>>> Sent: Monday, July 30, 2012 3:15 PM
>>> To: [email-masked]
>>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>>
>>> I am finding this document quite confusing.
>>>
>>> The primary confusion is that the document first says that it is about
>>> information that can not be manipulated with existing systems, and then
>>> proceeds to give a list of use cases all of which can be manipulated
>>> with existing systems at a suitable degree of abstraction.
>>>
>>> As a lesser confusion, the document says that "streaming" is important,
>>> but then describes "streaming" as "fast, interactive access."  That is
>>> not streaming.  And depending upon what one means by interactive, plenty
>>> of systems provide "fest, interactive access."  I realize the document
>>> later goes on tot talk about speed and frequency of state updates.   But
>>> that section simply reasserts the earlier terms withotu better
>>> description or justification.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>>
>>>>
>>>>       Title           : Interface to the Routing System Framework
>>>>       Author(s)       : Alia Atlas
>>>>                            Thomas Nadeau
>>>>                            Dave Ward
>>>>       Filename        : draft-ward-irs-framework-00.txt
>>>>       Pages           : 21
>>>>       Date            : 2012-07-30
>>>>
>>>> Abstract:
>>>>     This document describes a framework for a standard, programmatic
>>>>     interface for full-duplex, streaming state transfer in and out of the
>>>>     Internet's routing system.  It lists the information that might be
>>>>     exchanged over the interface, and describes the uses of an interface
>>>>     to the Internet routing system.
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: Alia Atlas <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Alia:

I'll try to create a bibliography of things people should read.  It will be mid-next week since I'm away from my home library on the SDN topic.

Sue 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Wednesday, August 01, 2012 3:51 PM
To: Susan Hares
Cc: Joel M. Halpern; [email-masked]
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Sue,

I look forward to talking with you more off-line on the policy and
local-pref research and issues.  If you have suggestions on good
background research to read, by all means send it to the list so
others can get up to speed as well.

On the atomic transaction semantics question, let's get a bit further
into the use-cases and framework - and then have a focused discussion.
 I'm not opposed to it forever or if it is necessary - just would like
to thoroughly analyze if it is a real requirement.

Do others have opinions and perspective on this?

Alia

On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]> wrote:
> Alia:
>
> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>
> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Monday, July 30, 2012 6:33 PM
> To: Susan Hares
> Cc: Joel M. Halpern; [email-masked]
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> Hi Sue,
>
> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote:
>> Joel and irs-folks:
>>
>> +1 on Joel.
>>
>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>
> [Alia] Can you further clarify, maybe with an example, which aspect
> you are thinking of?   Do you mean the ability of an application to
> access multiple sub-interfaces?  The interaction of operations
> requested by differerent applications?
>
>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>
> [Alia] I'm pretty sure that I avoided the word "transaction" in both
> drafts.  That was deliberate.  Of course, we can have a discussion
> about whether or not some form of transactions might be desirable.  I
> am concerned about their potentially heavy-weight nature.
>
>> Therefore, you've skipped even requiring the hard problems.
>
> [Alia] Can I optimistically pretend that means that the requirements
> we do have don't seem too hard?  For the responsiveness and throughput
> goals, I've put a stake in the ground to avoid transaction-based
> semantics.  Naturally, the hordes can run over that stake, if
> necessary.
>
> [Sue]: The requirements are necessary even if they are hard.
>
> [Alia] For the interaction between different layers of sub-interfaces,
> I've been assuming that we'll define the interactions between the
> layers based on how they are generally done.  For instance, perhaps we
> standardize the idea of preference value - and then the RIB can pick
> the best route based upon those preferences.  For interaction between
> different applications, I think there's a mixture of
> authorization/authentication to get right plus a good set of events
> that an application could register for.
>
> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>
> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>
>> Is this just the -00.draft?
>
> [Alia] Certainly, I expect that we'll uncover more requirements as we
> go along.  As I said, some of this is initially setting parts  out of
> scope.
>
> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>
> Alia
>
>> Sue
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>> Sent: Monday, July 30, 2012 3:15 PM
>> To: [email-masked]
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> I am finding this document quite confusing.
>>
>> The primary confusion is that the document first says that it is about
>> information that can not be manipulated with existing systems, and then
>> proceeds to give a list of use cases all of which can be manipulated
>> with existing systems at a suitable degree of abstraction.
>>
>> As a lesser confusion, the document says that "streaming" is important,
>> but then describes "streaming" as "fast, interactive access."  That is
>> not streaming.  And depending upon what one means by interactive, plenty
>> of systems provide "fest, interactive access."  I realize the document
>> later goes on tot talk about speed and frequency of state updates.   But
>> that section simply reasserts the earlier terms withotu better
>> description or justification.
>>
>> Yours,
>> Joel
>>
>> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>       Title           : Interface to the Routing System Framework
>>>       Author(s)       : Alia Atlas
>>>                            Thomas Nadeau
>>>                            Dave Ward
>>>       Filename        : draft-ward-irs-framework-00.txt
>>>       Pages           : 21
>>>       Date            : 2012-07-30
>>>
>>> Abstract:
>>>     This document describes a framework for a standard, programmatic
>>>     interface for full-duplex, streaming state transfer in and out of the
>>>     Internet's routing system.  It lists the information that might be
>>>     exchanged over the interface, and describes the uses of an interface
>>>     to the Internet routing system.
>>>
>> _______________________________________________
>> 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: Wed, 1 Aug 2012 18:51:14 -0400
From: Alia Atlas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Sue,

I look forward to talking with you more off-line on the policy and
local-pref research and issues.  If you have suggestions on good
background research to read, by all means send it to the list so
others can get up to speed as well.

On the atomic transaction semantics question, let's get a bit further
into the use-cases and framework - and then have a focused discussion.
 I'm not opposed to it forever or if it is necessary - just would like
to thoroughly analyze if it is a real requirement.

Do others have opinions and perspective on this?

Alia

On Wed, Aug 1, 2012 at 1:58 PM, Susan Hares <[email-masked]> wrote:
> Alia:
>
> The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".
>
> It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility.
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Monday, July 30, 2012 6:33 PM
> To: Susan Hares
> Cc: Joel M. Halpern; [email-masked]
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> Hi Sue,
>
> On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote:
>> Joel and irs-folks:
>>
>> +1 on Joel.
>>
>>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.
>
> [Alia] Can you further clarify, maybe with an example, which aspect
> you are thinking of?   Do you mean the ability of an application to
> access multiple sub-interfaces?  The interaction of operations
> requested by differerent applications?
>
>> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.
>
> [Alia] I'm pretty sure that I avoided the word "transaction" in both
> drafts.  That was deliberate.  Of course, we can have a discussion
> about whether or not some form of transactions might be desirable.  I
> am concerned about their potentially heavy-weight nature.
>
>> Therefore, you've skipped even requiring the hard problems.
>
> [Alia] Can I optimistically pretend that means that the requirements
> we do have don't seem too hard?  For the responsiveness and throughput
> goals, I've put a stake in the ground to avoid transaction-based
> semantics.  Naturally, the hordes can run over that stake, if
> necessary.
>
> [Sue]: The requirements are necessary even if they are hard.
>
> [Alia] For the interaction between different layers of sub-interfaces,
> I've been assuming that we'll define the interactions between the
> layers based on how they are generally done.  For instance, perhaps we
> standardize the idea of preference value - and then the RIB can pick
> the best route based upon those preferences.  For interaction between
> different applications, I think there's a mixture of
> authorization/authentication to get right plus a good set of events
> that an application could register for.
>
> [Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.
>
> The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.
>
>> Is this just the -00.draft?
>
> [Alia] Certainly, I expect that we'll uncover more requirements as we
> go along.  As I said, some of this is initially setting parts  out of
> scope.
>
> ---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.
>
> Alia
>
>> Sue
>>
>>
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
>> Sent: Monday, July 30, 2012 3:15 PM
>> To: [email-masked]
>> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>>
>> I am finding this document quite confusing.
>>
>> The primary confusion is that the document first says that it is about
>> information that can not be manipulated with existing systems, and then
>> proceeds to give a list of use cases all of which can be manipulated
>> with existing systems at a suitable degree of abstraction.
>>
>> As a lesser confusion, the document says that "streaming" is important,
>> but then describes "streaming" as "fast, interactive access."  That is
>> not streaming.  And depending upon what one means by interactive, plenty
>> of systems provide "fest, interactive access."  I realize the document
>> later goes on tot talk about speed and frequency of state updates.   But
>> that section simply reasserts the earlier terms withotu better
>> description or justification.
>>
>> Yours,
>> Joel
>>
>> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>>
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>
>>>
>>>       Title           : Interface to the Routing System Framework
>>>       Author(s)       : Alia Atlas
>>>                            Thomas Nadeau
>>>                            Dave Ward
>>>       Filename        : draft-ward-irs-framework-00.txt
>>>       Pages           : 21
>>>       Date            : 2012-07-30
>>>
>>> Abstract:
>>>     This document describes a framework for a standard, programmatic
>>>     interface for full-duplex, streaming state transfer in and out of the
>>>     Internet's routing system.  It lists the information that might be
>>>     exchanged over the interface, and describes the uses of an interface
>>>     to the Internet routing system.
>>>
>> _______________________________________________
>> 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: Wed, 1 Aug 2012 18:40:32 -0400
From: Alia Atlas <[email-masked]>
To: Susan Hares <[email-masked]>
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Sue,

In this case, I was thinking of "translating" from a "higher
abstraction layer" to a "lower abstraction layer".

Do you have a better/different term to suggest?  I agree that clarity
of terminology is important.

Alia

On Wed, Aug 1, 2012 at 2:03 PM, Susan Hares <[email-masked]> wrote:
> Alia:
>
> +1 on abstraction + filters (abstract/detail) IRS fits at the routing control.
>
> The real question about translation is what the translation is doing.  Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change.
>
> I define translation as the same layer of abstraction.  Some people suggest translation = abstract/detailing.  We first need a common way to talk about the difference.
>
> Sue
>
> By the way --- I'm thrilled about the pace of the discussion.
>
>
> -----Original Message-----
> From: Alia Atlas [mailto:[email-masked]]
> Sent: Monday, July 30, 2012 6:40 PM
> To: Susan Hares
> Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Sue,
>
> I certainly agree that we want IRS to have the ability to express
> information at different abstraction layers and filtered on request.
>
> There may still be a gap between the "network OS abstractions" and IRS
> sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
> the bottom-up control strings.
>
> IMHO, it's reasonable to have an entity that manages the translation.
> For instance, one doesn't need a PCE-equiv in every application - nor
> in every router; that might be an entity in between.
>
> The quantity of information is part of why explicit filtering and
> hopefully abstraction layers should be built into the data-models.
>
> Alia
>
> On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked]> wrote:
>> Nitin:
>>
>> Exposing some network intelligence can either be done in detail or in some amount of summarization.
>> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information.
>>
>> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.
>>
>> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.
>>
>> If we have an Interface to routing, it need to have a two-layer concept of exposing information.
>>
>> Sue Hares
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
>> Sent: Monday, July 30, 2012 3:33 PM
>> To: James Kempf; Thomas Nadeau; [email-masked]
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Hi James,
>>
>> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
>> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
>> network element's RIB (not the FIB directly).
>>
>> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
>>
>> Hope that helps.
>>
>> Thanks
>> Nitin
>>
>> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:
>>
>> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>>
>> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>>
>>                 jak
>>
>>> -----Original Message-----
>>> From: [email-masked]
>>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>>> Sent: Monday, July 30, 2012 11:18 AM
>>> To: [email-masked]
>>> Subject: [irs-discuss] IRS Problem Statement Posted
>>>
>>>
>>>
>>> Please review and discuss.
>>>
>>> Thanks,
>>>
>>> Tom, Alia, Ward
>>>
>>>
>>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>>
>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: Russ White <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 1 Aug 2012 19:38:00 +0000
Accept-Language: en-US, zh-CN
Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework

Russ: 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ White
Sent: Tuesday, July 31, 2012 5:42 PM
To: [email-masked]
Subject: [irs-discuss] Thoughts on draft-ward-irs-framework

This framework is well put together, but I'd like to make a couple of
suggestions/comments/put some ideas forward.

1. I think the draft struggles somewhat with describing something that's
already in all routers today because it's attempting to describe an
interface into the RIB that's somehow separate, or stands beside, the
existing interfaces into the RIB. I would gently suggest that describing
this entire idea as an "off board routing process," much like a BGP
process on an existing implementation, might clarify things a bit, and
make the model easier to understand.

Consider --any given routing process already installs routes into the
routing table, including the concept of preference. BGP routing
processes, specifically, also have import and export capabilities into
various VRFs. All routing processes also have redistribution capabilities.

What if you modeled this entire thing as two types of "off board routing
processes," one that only imports data from the RIB for northbound
consumption (topology information), and one that interacts with the RIB
like any other routing process would for southbound control as well as
northbound consumption?

----> [Russ]: +1 - This Offboard controller processing aligns with the ONF view of SDN.  And it has been done in practice for 10+ years. However as you know, the timing between the calculation and download to HW is important. 

It's going to be much easier to interact with the other routing
protocols on the box without a lot of "special pleading" if IRS is a
process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of
link down notifications --all the implementations I know of process link
downs in the RIB, and the RIB then notifies the routing protocol... If
you're hooking into the RIB locally, then, you need to hook into link
down detection specifically and intentionally. If IRS is a routing
process, the RIB will notify the northbound interface as a matter of
course in processing link down notifications.

I hope that makes sense, but I'm glad to sit and discuss if it doesn't.

2. There needs to be a way to mark routes inserted in the RIB with a
process ID of some sort. This would come naturally if the entire IRS
idea were to put an "off board routing process" on the box that
interacts with existing on board processes (see #1 above), but as the
draft stands, there's no way to insert a process id into the RIB. This
is crucial for redistribution, and I suspect redistribution is going to
be a huge problem to address in the long term, since the routes injected
by IRS, however they're injected, will need to interact with the dynamic
protocols running on the box.

[Sue] See our work on Route servers (1990-1995) and current work - for an example.
This is what I mentioned above. 

3. There are a ton of other possible use cases, if more are
needed/wanted to support the reasoning behind the draft. Choosing the
optimal exit from any given edge (OER in cisco lingo), a superset of
Flowspec to combat DDoS is another (mentioned tangentially, but not as a
use case), live/live is another (packet replication and choosing the
best of two identical streams) --and there are others... Some of these
might actually be more interesting use cases than are currently
described in the draft.

More if I get the chance to reread it in a little more depth later.

Sue: Use cases are key.  The clarity of the use cases will guide us.  Please send USE cases.

Russ

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

From: Susan Hares <[email-masked]>
To: Nitin Bahadur <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Nitin:

Thanks for the agreement.  The real challenge is how to fit the middleware into the needs of application and network layer.  Framework, architecture, design steps have fascinating challenges that build on the 30+ years of distributed and centralized networking algorithms. 

Two things often forgotten in these models are security and mobility.  In the DC & VM-aware world, we cannot skips these two items. 

As a side note,  John Day in Patterns of Networking - suggests that all of networking can be viewed as middleware. For in the end - we are multiplexing application traffic over some media.  Networks exist to provide service to applications.  

Sue 
[love this discussion!]

-----Original Message-----
From: Nitin Bahadur [mailto:[email-masked]] 
Sent: Monday, July 30, 2012 6:39 PM
To: Susan Hares
Cc: James Kempf; Thomas Nadeau; [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Hi Susan,

    You've expressed my thoughts very succinctly. I fully agree with all you said. IRS is nothing but a middleware IMO. 

An orchestrator has 3 layers:

The top layer exposes the northbound Apis to apps - I want a path from A to B with a constrain on low latency. That's all the app should need to say.

The bottom layer fetches topology, stats and other data from network elements and programs the network elements.

And the middle layer is the business layer that takes user input from northbound Apis, takes input from bottom layer; munches on the data and converts it into rules for the bottom layer to program.

So IRS needs to define interfaces for both the lower layer and the upper layer.

Thanks
Nitin

On Jul 30, 2012, at 6:27 PM, "Susan Hares" <[email-masked]> wrote:

> Nitin: 
> 
> Exposing some network intelligence can either be done in detail or in some amount of summarization. 
> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information. 
> 
> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.  
> 
> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.  
> 
> If we have an Interface to routing, it need to have a two-layer concept of exposing information.  
> 
> Sue Hares 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: Monday, July 30, 2012 3:33 PM
> To: James Kempf; Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
> 
> Hi James,
> 
> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
> network element's RIB (not the FIB directly).
> 
> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
> 
> Hope that helps.
> 
> Thanks
> Nitin
> 
> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:
> 
> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
> 
> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
> 
>                jak
> 
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>> Sent: Monday, July 30, 2012 11:18 AM
>> To: [email-masked]
>> Subject: [irs-discuss] IRS Problem Statement Posted
>> 
>> 
>> 
>> Please review and discuss.
>> 
>> Thanks,
>> 
>> Tom, Alia, Ward
>> 
>> 
>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>> 
>> 
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: Alia Atlas <[email-masked]>
Accept-Language: en-US, zh-CN
Cc: Thomas Nadeau <[email-masked]>, Nitin Bahadur <[email-masked]>, James Kempf <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Alia:

+1 on abstraction + filters (abstract/detail) IRS fits at the routing control.  

The real question about translation is what the translation is doing.  Is it translating one thing to another at the same layer of abstraction (e.g., Spanish/English, Ascii/ebcdic) or is it doing abstraction/detail change. 

I define translation as the same layer of abstraction.  Some people suggest translation = abstract/detailing.  We first need a common way to talk about the difference. 

Sue

By the way --- I'm thrilled about the pace of the discussion. 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Monday, July 30, 2012 6:40 PM
To: Susan Hares
Cc: Nitin Bahadur; James Kempf; Thomas Nadeau; [email-masked]
Subject: Re: [irs-discuss] IRS Problem Statement Posted

Sue,

I certainly agree that we want IRS to have the ability to express
information at different abstraction layers and filtered on request.

There may still be a gap between the "network OS abstractions" and IRS
sub-interfaces; I'd be surprised if there weren't.  IRS is to provide
the bottom-up control strings.

IMHO, it's reasonable to have an entity that manages the translation.
For instance, one doesn't need a PCE-equiv in every application - nor
in every router; that might be an entity in between.

The quantity of information is part of why explicit filtering and
hopefully abstraction layers should be built into the data-models.

Alia

On Mon, Jul 30, 2012 at 9:24 PM, Susan Hares <[email-masked]> wrote:
> Nitin:
>
> Exposing some network intelligence can either be done in detail or in some amount of summarization.
> If you are doing detail, you have bandwidth issues. If you are doing summarization or opacity, you are talking about layers of information.
>
> Apps need to find out what they need to get. They do not need all the details - just the fact they can get from point A to Point B (or for multi-cast B/C/D). They need to where they can go to date other applications.  They need a match-maker for the application who determine where the applications shall flow.  Now, if they are smart - like people going out to eat - they pick several ways go to eat traffic.
>
> The network orchestration then serves to be the paths to the place to eat.  This can either be distributed or centralized.
>
> If we have an Interface to routing, it need to have a two-layer concept of exposing information.
>
> Sue Hares
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Nitin Bahadur
> Sent: Monday, July 30, 2012 3:33 PM
> To: James Kempf; Thomas Nadeau; [email-masked]
> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>
> Hi James,
>
> This is not about splitting control plane and forwarding plane. It is about exposing network intelligence in the network elements to an external controller.
> And it is about allowing an external controller to use that information for enabling network-aware apps. And it is about allowing apps to influence the
> network element's RIB (not the FIB directly).
>
> Streaming is essential to allow for operations at scale...and avoid a request/response gated mechanism.
>
> Hope that helps.
>
> Thanks
> Nitin
>
> On 7/30/12 3:11 PM, "James Kempf" <[email-masked]> wrote:
>
> I don't understand why streaming is specified in this draft. And I don't understand why this draft isn't put in the Forces framework. Forces is a framework explicitedly designed for device to controller communication. Its major drawback it that it is a framework with a hole in the middle, in that there are no specified devices. This draft would fill that hole.
>
> I don't think it is necessary to have a problem statement for router state update. Forces has already established that splitting the control plane into a separate device is, in some cases, an attractive design option. So I think this should be submitted to the Forces working group, or, at least, recast in the Forces framework.
>
>                 jak
>
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Thomas Nadeau
>> Sent: Monday, July 30, 2012 11:18 AM
>> To: [email-masked]
>> Subject: [irs-discuss] IRS Problem Statement Posted
>>
>>
>>
>> Please review and discuss.
>>
>> Thanks,
>>
>> Tom, Alia, Ward
>>
>>
>> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>>
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

From: Susan Hares <[email-masked]>
To: Alia Atlas <[email-masked]>
Date: Wed, 1 Aug 2012 17:58:09 +0000
Accept-Language: en-US, zh-CN
Cc: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Alia:

The hierarchical of interfaces (To routing system) is one of the areas that requires prioritization. The prioritization must be able to handle "preempt me", "after you", and "after me".  

It is also key to understand that irs system must handle multi-interfaces struggles at the lowest layer.  You need to look at the MIF WG (+/-) for some of the struggles of mobility. 

-----Original Message-----
From: Alia Atlas [mailto:[email-masked]] 
Sent: Monday, July 30, 2012 6:33 PM
To: Susan Hares
Cc: Joel M. Halpern; [email-masked]
Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt

Hi Sue,

On Mon, Jul 30, 2012 at 9:16 PM, Susan Hares <[email-masked]> wrote:
> Joel and irs-folks:
>
> +1 on Joel.
>
>  Beyond your comments, the requirement prioritization of the interworking of these interfaces is not clearly delineated in this work. This type of prioritization and sequencing is key to multi-interfaces operation on the monitoring, configuration or insertion of information into the depth.

[Alia] Can you further clarify, maybe with an example, which aspect
you are thinking of?   Do you mean the ability of an application to
access multiple sub-interfaces?  The interaction of operations
requested by differerent applications?

> In addition, if you are going to do configuration with roll-forward/roll-back - you need a transaction based processing.

[Alia] I'm pretty sure that I avoided the word "transaction" in both
drafts.  That was deliberate.  Of course, we can have a discussion
about whether or not some form of transactions might be desirable.  I
am concerned about their potentially heavy-weight nature.

> Therefore, you've skipped even requiring the hard problems.

[Alia] Can I optimistically pretend that means that the requirements
we do have don't seem too hard?  For the responsiveness and throughput
goals, I've put a stake in the ground to avoid transaction-based
semantics.  Naturally, the hordes can run over that stake, if
necessary.

[Sue]: The requirements are necessary even if they are hard.  

[Alia] For the interaction between different layers of sub-interfaces,
I've been assuming that we'll define the interactions between the
layers based on how they are generally done.  For instance, perhaps we
standardize the idea of preference value - and then the RIB can pick
the best route based upon those preferences.  For interaction between
different applications, I think there's a mixture of
authorization/authentication to get right plus a good set of events
that an application could register for.

[Sue]: As someone who has lived with "local pref" in BGP for a long time, there is a bit more to unwrap in the statement.  However, it breaks down to prioritization that is pre-set by preferences.

The policy issues behind the local-pref setting have been studied by the BGP policy community. This is substantial good work on this from the academic researchers, vendors, and operator. Griffins, Rexford, Bush, Feamster, ..... and lots others are much better on the theory than I am.  

> Is this just the -00.draft?

[Alia] Certainly, I expect that we'll uncover more requirements as we
go along.  As I said, some of this is initially setting parts  out of
scope.

---> Scope == good.  Setting scope allows us to pick a piece of this work and standardize it for interoperability.

Alia

> Sue
>
>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joel M. Halpern
> Sent: Monday, July 30, 2012 3:15 PM
> To: [email-masked]
> Subject: Re: [irs-discuss] I-D Action: draft-ward-irs-framework-00.txt
>
> I am finding this document quite confusing.
>
> The primary confusion is that the document first says that it is about
> information that can not be manipulated with existing systems, and then
> proceeds to give a list of use cases all of which can be manipulated
> with existing systems at a suitable degree of abstraction.
>
> As a lesser confusion, the document says that "streaming" is important,
> but then describes "streaming" as "fast, interactive access."  That is
> not streaming.  And depending upon what one means by interactive, plenty
> of systems provide "fest, interactive access."  I realize the document
> later goes on tot talk about speed and frequency of state updates.   But
> that section simply reasserts the earlier terms withotu better
> description or justification.
>
> Yours,
> Joel
>
> On 7/30/2012 2:08 PM, [email-masked] wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>
>>
>>       Title           : Interface to the Routing System Framework
>>       Author(s)       : Alia Atlas
>>                            Thomas Nadeau
>>                            Dave Ward
>>       Filename        : draft-ward-irs-framework-00.txt
>>       Pages           : 21
>>       Date            : 2012-07-30
>>
>> Abstract:
>>     This document describes a framework for a standard, programmatic
>>     interface for full-duplex, streaming state transfer in and out of the
>>     Internet's routing system.  It lists the information that might be
>>     exchanged over the interface, and describes the uses of an interface
>>     to the Internet routing system.
>>
> _______________________________________________
> 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: Wed, 1 Aug 2012 09:52:21 -0400
From: Alia Atlas <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] Thoughts on draft-ward-irs-framework

Hi Russ,

Thanks for the good suggestions and comments.

I do agree that an internal representation for the IRS as it interacts
with the RIB and learning events is basically as "another routing
process" and those are the general semantics to describe.  One
difference, though, is the idea that different static routes installed
by IRS may want to have different preference values.

I also think that describing the IRS sub-interface for installing
static routes in such a fashion would provide the necessary process id
tag for origin in the RIB.  If more detail is needed, then that can
give a correct path to query.

I do think these aspects are more on the internal implementation side
than on the data-model or information-model side.  As much as they are
useful to describe the desired interactions, I think they are good to
capture.

On use-cases, I would be delighted to have your thoughts on examples
written down, even in email to the list.   What is in the framework
draft is explicitly not the motivating use-cases, but just some
instances of what is possible with the described IRS sub-interfaces.

If there is sufficient interest in IRS, I think that one of the first
focuses needs to be identifying a few (2-4) vertical use-cases with
feedback loops (topology, events, measurements up as well as installed
state down) that we can use to drive the data-model definitions and
desired functionality.

Thanks,
Alia

On Tue, Jul 31, 2012 at 8:41 PM, Russ White <[email-masked]> wrote:
>
> This framework is well put together, but I'd like to make a couple of
> suggestions/comments/put some ideas forward.
>
> 1. I think the draft struggles somewhat with describing something that's
> already in all routers today because it's attempting to describe an
> interface into the RIB that's somehow separate, or stands beside, the
> existing interfaces into the RIB. I would gently suggest that describing
> this entire idea as an "off board routing process," much like a BGP
> process on an existing implementation, might clarify things a bit, and
> make the model easier to understand.
>
> Consider --any given routing process already installs routes into the
> routing table, including the concept of preference. BGP routing
> processes, specifically, also have import and export capabilities into
> various VRFs. All routing processes also have redistribution capabilities.
>
> What if you modeled this entire thing as two types of "off board routing
> processes," one that only imports data from the RIB for northbound
> consumption (topology information), and one that interacts with the RIB
> like any other routing process would for southbound control as well as
> northbound consumption?
>
> It's going to be much easier to interact with the other routing
> protocols on the box without a lot of "special pleading" if IRS is a
> process that's peer to BGP, OSPF, IS-IS, et al. Take the instance of
> link down notifications --all the implementations I know of process link
> downs in the RIB, and the RIB then notifies the routing protocol... If
> you're hooking into the RIB locally, then, you need to hook into link
> down detection specifically and intentionally. If IRS is a routing
> process, the RIB will notify the northbound interface as a matter of
> course in processing link down notifications.
>
> I hope that makes sense, but I'm glad to sit and discuss if it doesn't.
>
> 2. There needs to be a way to mark routes inserted in the RIB with a
> process ID of some sort. This would come naturally if the entire IRS
> idea were to put an "off board routing process" on the box that
> interacts with existing on board processes (see #1 above), but as the
> draft stands, there's no way to insert a process id into the RIB. This
> is crucial for redistribution, and I suspect redistribution is going to
> be a huge problem to address in the long term, since the routes injected
> by IRS, however they're injected, will need to interact with the dynamic
> protocols running on the box.
>
> 3. There are a ton of other possible use cases, if more are
> needed/wanted to support the reasoning behind the draft. Choosing the
> optimal exit from any given edge (OER in cisco lingo), a superset of
> Flowspec to combat DDoS is another (mentioned tangentially, but not as a
> use case), live/live is another (packet replication and choosing the
> best of two identical streams) --and there are others... Some of these
> might actually be more interesting use cases than are currently
> described in the draft.
>
> More if I get the chance to reread it in a little more depth later.
>
> HTH
>
> Russ
>
> --
> <><
> [email-masked]
> [email-masked]
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss