Subject: Re: [irs-discuss] IRS comments

From: Lin Han <[email-masked]>
Date: Wed, 8 Aug 2012 23:14:44 +0000

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

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 8 Aug 2012 19:21:58 -0400

On 8/8/12 7:14 PM, "Lin Han" <[email-masked]> wrote:

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

>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

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

---

From: Thomas Nadeau <[email-masked]>
Date: Wed, 8 Aug 2012 19:53:18 -0400

The slides can be found here:

http://www.lucidvision.com/draft-ward-irs-framework-00.pptx

---

From: Lin Han <[email-masked]>
Date: Wed, 8 Aug 2012 23:56:10 +0000

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

	--Tom

---

From: Alia Atlas <[email-masked]>
Date: Wed, 8 Aug 2012 20:42:43 -0400

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

---

From: Lin Han <[email-masked]>
Date: Thu, 9 Aug 2012 01:51:17 +0000

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,

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

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

Alia

---

From: Susan Hares <[email-masked]>
Date: Thu, 9 Aug 2012 14:57:36 +0000

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,

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]

	--Tom

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 09 Aug 2012 17:03:12 +0200

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.
>
> -----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,
>
> 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
>
>
>> -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]
> _______________________________________________ irs-discuss mailing
> list [email-masked]
> _______________________________________________ irs-discuss mailing
> list [email-masked]

---

From: Thomas Nadeau <[email-masked]>
Date: Thu, 9 Aug 2012 12:38:12 -0400

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

---

From: Gert Grammel <[email-masked]>
Date: Thu, 9 Aug 2012 20:59:43 +0100

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]

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 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Gert Grammel
> 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).
>> -4.1.3 "There is no bidirectional programmatic interface to add,
modify,
>> -4.1.3 "The multicast state added need not match to well-known
protocol
>> -"IRS"- you may want to select a different acronym that isn't related

>> to something as unpopular as taxation (something we learned with
AMT).
>> 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
>

---

From: Susan Hares <[email-masked]>
Date: Fri, 10 Aug 2012 01:51:36 +0000

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,

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

Tom 

modify,
protocol

AMT).

---

From: Scott Whyte <[email-masked]>
Date: Fri, 10 Aug 2012 16:22:53 -0700

> 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

-- 
panem et circenses - a winning strategy for over 2000 years!

---

From: Alia Atlas <[email-masked]>
Date: Fri, 10 Aug 2012 20:16:46 -0400

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

---

From: Scott Whyte <[email-masked]>
Date: Fri, 10 Aug 2012 18:03:11 -0700

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

> good semantics and interactions.  Obviously, implementations may

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

---

From: Alia Atlas <[email-masked]>
Date: Mon, 13 Aug 2012 08:41:28 -0400

...snip...

> 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

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 15 Aug 2012 07:41:26 -0400

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

> 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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 09:07:39 -0400

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

---

From: Olen Stokes <[email-masked]>
Date: Wed, 15 Aug 2012 06:43:27 -0700

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:
> 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.
>
> [mailto:[email-masked]] On Behalf Of Alia Atlas
>>> 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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 10:23:22 -0400

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

---

From: "David Lake (dlake)" <[email-masked]>
Date: Wed, 15 Aug 2012 15:40:34 +0000

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:
>>> operator to whatever precedence they want, I agree.  Its not clear 
>>> to me if various RIB implementations treat all proffered routes the 
>>> routing processes, if they so desire.  OTOH if it can all be done 
>>> via static routes, it seems much simpler. :)
>>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 11:48:20 -0400

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

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 15 Aug 2012 22:17:40 +0530

+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

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,

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 12:50:04 -0400

This is why I want to focus on use-cases.  From there, I think we can
develop realistic requirements.   Feel free to contribute :-)

Alia

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Wed, 15 Aug 2012 22:29:23 +0530

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

Alia

---

From: "David Lake (dlake)" <[email-masked]>
Date: Wed, 15 Aug 2012 17:11:55 +0000

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

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 10:22:42 -0700

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

> > 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
> >
> > 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.
> >
> 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
> >
> >> 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
> >>
> sub-interfaces along with an associated protocol (whether that is a new one
> or extending an existing one).
> >>
> >> Alia
> >>
> >>> 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.
> >>>
> >>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent predictive
> action/response/events even when different implementations has varying
> capabilities.
> >>>
> 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

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 10:24:22 -0700

s/wg/pre-BOF proto-wg :P/g

---

From: Olen Stokes <[email-masked]>
Date: Wed, 15 Aug 2012 10:30:21 -0700

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,

Alia

On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake) <[email-masked]<mailto:[email-masked]>> wrote:
> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
> Cc: [email-masked]<mailto:[email-masked]>
> On Wed, Aug 15, 2012 at 9:43 AM, Olen Stokes <[email-masked]<mailto:[email-masked]>> wrote:
>> From: [email-masked]<mailto:[email-masked]>
>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>> Cc: Gert Grammel; [email-masked]<mailto:[email-masked]>; Lenny Giuliano; Thomas Nadeau;
>> Alia Atlas; Scott Whyte
>> On Wed, Aug 15, 2012 at 7:41 AM, Shah, Himanshu <[email-masked]<mailto:[email-masked]>> wrote:
>>> From: [email-masked]<mailto:[email-masked]>
>>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
>>> Cc: Thomas Nadeau; Gert Grammel; Alia Atlas; Lenny Giuliano;
>>> [email-masked]<mailto:[email-masked]>
>>> 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:
>>>
>>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>
_______________________________________________
irs-discuss mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 13:36:03 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 13:36:56 -0400

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

---

From: "David Lake (dlake)" <[email-masked]>
Date: Wed, 15 Aug 2012 17:38:32 +0000

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:
>>>>>> gives good semantics and interactions.  Obviously, 
>>>>>> implementations may differ.
>>>>>
>>>>> to me if various RIB implementations treat all proffered routes 
>>>>> the same, nor if they store the same meta-data with all protocol sources.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 13:48:58 -0400

Sounds good.  Let me know if/when you'd like me to review it.

Alia

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 11:20:07 -0700

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:***
> *
>
> the controller, which are in turn translated to the appropriate PDUs.****
>
> ** **
>
> party :P) for the wg.  ****
>
> ** **
>
> my 2c. ****
>
> ** **
>
> On Wed, Aug 15, 2012 at 8:48 AM, Alia Atlas <[email-masked]> wrote:****
>
> Hi David,
>
> Alia****
> https://www.ietf.org/mailman/listinfo/irs-discuss****
>
> ** **
>
> ** **
>

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 15 Aug 2012 14:21:28 -0400

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

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

my 2c.

Alia

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 11:26:13 -0700

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

---

From: Olen Stokes <[email-masked]>
Date: Wed, 15 Aug 2012 11:38:01 -0700

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

my 2c.

Alia

---

From: Edward Crabbe <[email-masked]>
Date: Wed, 15 Aug 2012 11:56:49 -0700

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****
>
> ** **
>
> *Sent:* Wednesday, August 15, 2012 2:20 PM
> *To:* Olen Stokes
> *Cc:* Alia Atlas; David Lake (dlake); [email-masked]
>
> actual PDUs understood by the NEs. ****
>
> ** **
>
> On Wed, Aug 15, 2012 at 10:30 AM, Olen Stokes <[email-masked]>
> wrote:****
>
>  ****
>  ****
> *Cc:* David Lake (dlake); Olen Stokes; [email-masked]****
>
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 15 Aug 2012 21:50:25 +0200

>   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: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 18:04:40 -0400

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
>
> (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
> geographically dispersed) resource points.
>
>
>
> In hierarchical fashion:   Application server <- (application interface) ->
> Network Controller <- (IRS) -> Network Node
>
>
>
> 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
>
> I broad brushed and simplified a lot here to express my view – not sure if
> this jives with others.
>
>
>
> /Himanshu
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Thanks.  Can you also give us what you mean by “controller”.
>
>
>
> Olen
>
>
>
>> 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.
>>
>> 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
>> 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
>>
>> 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
>>
>>>> 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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 18:09:06 -0400

> 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

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?

>> When an XaaS processes a request it takes into consideration of
>> 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
>>
>> In hierarchical fashion:   Application server <- (application interface)
>> -> Network Controller <- (IRS) -> Network Node
>>
>>
>>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 18:10:12 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 18:11:56 -0400

On Wed, Aug 15, 2012 at 3:50 PM, Robert Raszuk <[email-masked]> wrote:
> 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

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 15 Aug 2012 18:57:13 -0400

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

Alia

On Wed, Aug 15, 2012 at 2:21 PM, Shah, Himanshu <[email-masked]> wrote:
> availability of the CPU, memory, application data, cost of power, etc. 
> to instantiate a VM on some host machine.
>
> (Centralized) Network "Controller(s)"  knows current state of network 
> nodes using IRS.
> The "use case" here is to be able to dynamically create L2/L2.5/L3 
> As we heard at IETF, IRS has tentacles in network nodes from BGP 
> policies, all the way down to FIBs/LFIBs/ACL.
>
>
>
> LSDB ( I saw an email which talks about reducing IGP to link 
> distribution protocol and running SPF in centralized network 
> controller)
>
> LIB
>
> FIB
>
> [mailto:[email-masked]] On Behalf Of Olen Stokes
> +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.
>
>
>
>> The draft talks very much as if the application we are addressing is 
>> an OSS/BSS system, essentially provisioning from the domain owner.
>>
>> customers/users at the first Open Network Summit, there appears to be 
>> a desire for cross-domain and user-land application integration.
>>
>> 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
>> general use-cases draft based on the three use-cases that he sent to the list.
>>
>> Alia
>>
>>> 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
>>>
>>>> mails, so pardon the repeat if somebody has already raised the 
>>>> following as a concern.
>>>>
>>>> RIB/LFIB/FIB/IGPs/BGP/LSDBs etc etc  provide a consistent 
>>>> predictive action/response/events even when different 
>>>> implementations has varying capabilities.
>>>>
>>>> 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

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Wed, 15 Aug 2012 23:50:08 +0000

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

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

Alia

---

From: Lin Han <[email-masked]>
Date: Thu, 16 Aug 2012 01:56:30 +0000

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

Alia

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 15 Aug 2012 22:01:53 -0400

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

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

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.

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

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 22:47:47 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 22:53:31 -0400

Good questions.

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

IRS is the means :-)  We're working on defining that based on the requirements.

Alia

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 22:54:56 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Wed, 15 Aug 2012 22:56:45 -0400

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

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 16 Aug 2012 10:00:19 +0530

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

/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

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

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

Alia

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 16 Aug 2012 10:41:06 -0400

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

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

/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

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

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

Alia

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 16 Aug 2012 10:42:48 -0400

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:
> [mailto:[email-masked]] On Behalf Of Shah, Himanshu
>> infrastructure and (to be decided how much it) controls member
>> network nodes using IRS.
>>
>> +1 Alia.  There's been a lot of confusion over this term.  Having
>> +gone a few
>> 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.
>>
>>
>>
>> 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.
>>
>> On Wed, Aug 15, 2012 at 11:40 AM, David Lake (dlake)
>> <[email-masked]>
>> wrote:
>>> customers/users at the first Open Network Summit, there appears to
>>> be a desire for cross-domain and user-land application integration.
>>>
>>> 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
>>>
>>>>> 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.
>>>>>> 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

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 16 Aug 2012 21:44:14 +0530

"LSDB (I saw an email which talks about reducing IGP to link
> 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

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

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

/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

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

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

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 12:19:18 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 12:23:25 -0400

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

---snip---

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 12:34:43 -0400

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

---snip---

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Thu, 16 Aug 2012 22:09:53 +0530

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

Alia

---snip---

---

From: Ramon Casellas <[email-masked]>
Date: Thu, 16 Aug 2012 18:57:54 +0200

> 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]>
Date: Thu, 16 Aug 2012 14:46:32 -0400

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

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:
> From: Dutta, Pranjal K (Pranjal)
> [mailto:[email-masked]]

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 16 Aug 2012 14:56:37 -0400

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

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

---snip---

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 17 Aug 2012 05:11:14 +0530

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

Pranjal, all,

Best regards

Ramon

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 21:44:47 -0400

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

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

==snip===

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 21:48:02 -0400

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

> So for example, would IRS interface provide changing admin-status of an interface on a node?

===snip===

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 21:50:12 -0400

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

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

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 17 Aug 2012 07:36:14 +0530

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

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Aug 2012 02:06:54 +0000

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
>

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 22:11:24 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 22:13:16 -0400

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

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 17 Aug 2012 07:49:07 +0530

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

Alia

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Aug 2012 02:38:02 +0000

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,
> 
> > 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
> >
> >> -----邮件原件-----

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 22:46:17 -0400

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 16 Aug 2012 22:51:21 -0400

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

---

From: Mach Chen <[email-masked]>
Date: Fri, 17 Aug 2012 02:54:39 +0000

Hi Alia,

I originally mean the IRS client, sorry about the typo:-)

Best regards,
Mach

> 发送时间: 2012年8月17日 10:51
> 主题: Re: 答复: 答复: [irs-discuss] IRS comments
> 
> Hi Mach,
> 
> > 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
> >
> >> -----邮件原件-----
> >> >> 发件人: [email-masked]
> [mailto:[email-masked]]
> >> 代
> >> >> 表 Alia Atlas
> >> >> 发送时间: 2012年8月17日 9:45
> >> >> 收件人: Shah, Himanshu
> >> >> > Meaning, can an IRS interface user at both ends (node and controller)
> be a
> >> >> non-PCE entity and perform

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 17 Aug 2012 08:45:01 +0530

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,

Alia

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 17 Aug 2012 10:09:17 -0400

> 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 idea is definitely to allow direct use of the interface of that is operationally desired.

Tom

---

From: Acee Lindem <[email-masked]>
Date: Fri, 17 Aug 2012 12:30:17 -0400

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?

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 17 Aug 2012 15:21:55 -0400

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

Tom 

>> there's benefit to not requiring an application to understand too 
>> many different protocols.
>> 
>> seems what exactly PCEP does today. My understanding of IRS is that 
>> it may be complementary on topology discovery.
>>> 
>>> Best regards,
>>> Mach
>>> 
>>>> -----邮件原件-----
>>>>> Meaning, can an IRS interface user at both ends (node and 
>>>>> controller) be a

---

From: Thomas Nadeau <[email-masked]>
Date: Sat, 18 Aug 2012 07:12:24 -0400

> 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

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 11:58:54 -0700

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 30 Aug 2012 15:10:31 -0400

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

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 12:32:20 -0700

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:

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

---

From: Alia Atlas <[email-masked]>
Date: Thu, 30 Aug 2012 15:52:15 -0400

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:
> As someone who runs centralized te, I can tell you that in some environments
> / for some deployment types centralized spf works just fine.
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 31 Aug 2012 02:10:59 +0530

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

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

Alia

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 14:44:02 -0700

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****
>
> ** **
>  ------------------------------
>
> *Sent:* Thursday, August 30, 2012 11:59 AM
> *To:* Alia Atlas
> *Cc:* **Dutta, Pranjal K** (Pranjal); UTTARO, JAMES; **Shah, Himanshu**; *
> [email-masked]
> **
> Alia;****
> If there is ****
> 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:****
>
> On Thu, Aug 16, 2012 at 12:14 PM, **Dutta, Pranjal K** (Pranjal)
> > Pranjal****
> ---snip---****

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 31 Aug 2012 04:39:55 +0530

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

Alia;

If there is

Alia

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 16:12:29 -0700

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.****
>
> ** **
> *Sent:* Thursday, August 30, 2012 2:44 PM
>
> *To:* **Dutta, Pranjal K** (Pranjal)
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; **
> [email-masked]
> **
> please define 'operational model' ( and 'large' :) .  ****
>
> On Thu, Aug 30, 2012 at 1:40 PM, **Dutta, Pranjal K** (Pranjal) <
> [email-masked]> wrote:****
>
> Hi,****
>
> *Cc:* **Dutta, Pranjal K** (Pranjal); UTTARO, JAMES; **Shah, Himanshu**;
> [email-masked]****
>
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 31 Aug 2012 04:46:15 +0530

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

Sent: Thursday, August 30, 2012 4:12 PM

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.

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

Thanks,
Pranjal

Alia;

If there is

Alia

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 17:33:46 -0700

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 ?****
>
> ** **
> *Sent:* Thursday, August 30, 2012 4:12 PM
>
> [email-masked]**
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-01****
>
> On Thu, Aug 30, 2012 at 4:09 PM, **Dutta, Pranjal K** (Pranjal) <
> *Sent:* Thursday, August 30, 2012 2:44 PM****
>
>
> *To:* **Dutta, Pranjal K** (Pranjal)****
>
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; [email-masked]*
> ***
>
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 31 Aug 2012 06:31:15 +0530

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?

Sent: Thursday, August 30, 2012 5:34 PM

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 ?

Thanks,
Pranjal

Alia;

If there is

Alia

---

From: Edward Crabbe <[email-masked]>
Date: Thu, 30 Aug 2012 18:16:11 -0700

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?  ****
>
> ** **
> *Sent:* Thursday, August 30, 2012 5:34 PM
>
> SPF running given the use of constraints in the draft.   ****
>
> On Thu, Aug 30, 2012 at 4:16 PM, **Dutta, Pranjal K** (Pranjal) <
> *Sent:* Thursday, August 30, 2012 4:12 PM****
>
>
> *Cc:* Alia Atlas; UTTARO, JAMES; **Shah, Himanshu**; [email-masked]

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Fri, 31 Aug 2012 08:33:25 +0530

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

Sent: Thursday, August 30, 2012 6:16 PM

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.

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?

Thanks,
Pranjal

Alia;

If there is

Alia

---

From: Alia Atlas <[email-masked]>
Date: Thu, 30 Aug 2012 23:43:21 -0400

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:
> 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>
>
> On Thu, Aug 30, 2012 at 6:01 PM, Dutta, Pranjal K (Pranjal)
>> its CSPF or some form like that. Our concern was – is there a strong use
>>
>> On Thu, Aug 30, 2012 at 4:16 PM, Dutta, Pranjal K (Pranjal)
>> That doesn’t talk about centralized SPF, does it ?
>>
>>
>>
>> On Thu, Aug 30, 2012 at 4:09 PM, Dutta, Pranjal K (Pranjal)
>> ‘operational model’ = IETF draft that describes the use case.
>>
>> ‘large’ = 40K LSAs, 500 IGP nodes.
>>
>>
>>
>> On Thu, Aug 30, 2012 at 1:40 PM, Dutta, Pranjal K (Pranjal)
>> w.r.t routing. I would like to see an operational model how such centralized
>> SPF can
>>

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 31 Aug 2012 18:56:58 -0400

>decap as treating a particular label/prefix - though that may require

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

>ability to query for what capabilities are supported by the routing

	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

>>number
>>> its CSPF or some form like that. Our concern was  is there a strong
>>>use
>>>
>>> That doesn¹t talk about centralized SPF, does it ?
>>>
>>>
>>>
>>> Œoperational model¹ = IETF draft that describes the use case.
>>>
>>> Œlarge¹ = 40K LSAs, 500 IGP nodes.
>>>
>>>
>>>
>>>          I believe that¹s 10% of what overall work that router does
>>>today
>>>centralized