Re: [irs-discuss] IRS comments

[Alia Atlas <[e-mail]>]

Lin,

IRS is about applications being able to provide routing-related state
to a device and learn topology, measurement, relevant events, etc.
from the devices.   It is critical to enable a feedback loop so that
an application can knowledgeably determine what state needs to be
installed.

I think it is important to focus on the problem-statement, use-cases,
framework and requirements for IRS.

People will have their own perspectives on how this can relate to the
work going on in the ONF and other fora.  In the IETF at this stage, I
don't think it is really appropriate to do a serious compare/contrast
draft.    Certainly, if others disagree, I'd be happy to comment on
preliminary write-ups or drafts.

I believe that IRS offers a useful function for allowing services that
require applications to be able to dynamically program routing state.
That can be on devices that locally implement and use all, some, or
very little of the routing system.  A key component for a device is
the RIB layer that provides indirection and policy to determine which
state to install based upon preference and which applications have
installed it.

The discussion at the Routing Area open meeting did frame and provide
additional context.  I'd recommend listening to that if & when
possible as well as looking at the slides and drafts.

Alia

On Wed, Aug 8, 2012 at 7:56 PM, Lin Han <[e-mail]> wrote:
> Hi, Tom,
>
> I got the slide after digging tons of threads.
> I agree that we should have a tech talk about what is the difference of IRS and SDN/OF. This will make the frame work more convincing.
> For example, after looking at the picture of Alias slide page 5, It cannot stop me to think that IRS protocol does similar things as north bound API, or OF, depending on what is the format of table we are going to use.
> This frame work gave me a impression that we assume that we don't want to simplify router architecture (for example, keep routing protocol running on router; IRS is just an extra new component), then what we can provide the same thing (programming-ability) like SDN. Is this the best solution?
>
> Thanks
> Lin
> -----Original Message-----
> From: Thomas Nadeau [mailto:[e-mail]]
> Sent: Wednesday, August 08, 2012 4:22 PM
> To: Lin Han; Gert Grammel; Lenny Giuliano; Alia Atlas
> Cc: [e-mail]
> Subject: Re: IRS comments
>
>
>
> On 8/8/12 7:14 PM, "Lin Han" <[e-mail]> wrote:
>
>>Similar confusion by wisely avoidance -:)
>>
>>If possible, Someone can draw a simple picture of IRS location in a
>>router with existence of other components.
>
>         Did you see the slides that Alia sent out from the IETF Presentation?
> Unicast me if not and I will get them to you.
>
>>Also, I think people are confused by the comparison with SDN and OF. More
>>clarification will be helpful.
>
>         For that, we really should set up some internal tech talk thing. Slides
> can help, but having a decent presentation on this would go a long way.
> Let me see what we can do in this regard.
>
>         --Tom
>
>
>>
>>Lin
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]]
>>On Behalf Of Gert Grammel
>>Sent: Monday, July 30, 2012 6:41 PM
>>To: Thomas Nadeau; Lenny Giuliano; Alia Atlas
>>Cc: [e-mail]
>>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: [e-mail] <[e-mail]>
>>To: Lenny Giuliano; Alia Atlas
>>Cc: [e-mail] <[e-mail]>
>>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" <[e-mail]> 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
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>>_______________________________________________
>>irs-discuss mailing list
>>[e-mail]
>>https://www.ietf.org/mailman/listinfo/irs-discuss
>
> _______________________________________________
> irs-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/irs-discuss