Re: [irs-discuss] IRS Problem Statement Posted

[Alia Atlas <[e-mail]>]

Hi James,

The routing system components are certainly part of a router's control
plane - but not all of it.  The idea of IRS involves sub-interfaces to
the different layers in the routing system.

Can you clarify what you are asking as it relates to ForCES and IRS?
I don't feel that we're on the same page yet.

Alia


On Mon, Jul 30, 2012 at 6:48 PM, James Kempf <[e-mail]> wrote:
> Hi Alia,
>
> Perhaps you can explain to me the difference between the state involved in "the routing system (FIB, IGPs, BGP, RSVP-TE, etc.)" and the control plane? The last time I looked, these protocols were all involved in routing control and therefore could reasonably be characterized as components of the control plane, IMHO.
>
>                 jak
>
>> -----Original Message-----
>> From: Alia Atlas [mailto:[e-mail]]
>> Sent: Monday, July 30, 2012 3:27 PM
>> To: James Kempf
>> Cc: Thomas Nadeau; [e-mail]
>> Subject: Re: [irs-discuss] IRS Problem Statement Posted
>>
>> Hi James,
>>
>> Thanks for your thoughts.   Streaming (as I've heard) is not as good a
>> description of the desired interface attributes as described
>> in Sec 1.1, the functional overview.
>>
>> IRS is NOT about having interfaces to the forwarding plane.  That's
>> what ForCES is focused on.   This is about communication to a router
>> to install/retrieve routing state into the routing system (FIB, IGPs,
>> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control plane from the
>> router.
>>
>> Are you suggesting that ForCES should drastically expand its scope?
>>
>> Before we start debating what and whether to expand existing
>> protocols, I think we need a common understanding of the
>> problem we're trying to solve and the related framework.
>>
>> Alia
>>
>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf
>> <[e-mail]> wrote:
>> > I don't understand why streaming is specified in this
>> draft. And I don't understand why this draft isn't put in the
>> Forces framework. Forces is a framework explicitedly designed
>> for device to controller communication. Its major drawback it
>> that it is a framework with a hole in the middle, in that
>> there are no specified devices. This draft would fill that hole.
>> >
>> > I don't think it is necessary to have a problem statement
>> for router state update. Forces has already established that
>> splitting the control plane into a separate device is, in
>> some cases, an attractive design option. So I think this
>> should be submitted to the Forces working group, or, at
>> least, recast in the Forces framework.
>> >
>> >                 jak
>> >
>> >> -----Original Message-----
>> >> From: [e-mail]
>> >> [mailto:[e-mail]] On Behalf Of Thomas Nadeau
>> >> Sent: Monday, July 30, 2012 11:18 AM
>> >> To: [e-mail]
>> >> Subject: [irs-discuss] IRS Problem Statement Posted
>> >>
>> >>
>> >>
>> >> Please review and discuss.
>> >>
>> >> Thanks,
>> >>
>> >> Tom, Alia, Ward
>> >>
>> >>
>> >> http://lucidvision.com/draft-atlas-irs-problem-statement-00.txt
>> >>
>> >>
>> >> _______________________________________________
>> >> irs-discuss mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/irs-discuss
>> >>
>> > _______________________________________________
>> > irs-discuss mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/irs-discuss
>>