Re: [irs-discuss] IRS Problem Statement Posted

[Alia Atlas <[e-mail]>]

Joel,

As we define the requirements and use-cases, it's possible that
NetConf or ForCES or other options may appear as good options.

We might even want the ability to use different ones as the transfer
protocol; I'm not yet convinced.

The other strong requirement is around security, authorization,
authentication, roles, etc.  I think that will play a role in helping
define what protocols may be suitable to use or extend.

Alia

On Mon, Jul 30, 2012 at 6:39 PM, Joel M. Halpern <[e-mail]> wrote:
> Alia, I do have to disagree with one aspect of your characterization fo
> ForCES.  While the initial design goal was forwarding behavior, the protocol
> design is such that it is usable over a broad range of abstraction levels.
>
> Similarly, depending upon exactly what we need, netconf + Netmad/YANG may be
> suitable / useable.
>
> On the other hand, I think that working out the problems and entities that
> need to be modeled first (which probably does need a dedicated working
> group), and then worrying about which protocol meets the requirements when
> we know what exactly we need.  At that point, the protocol work can be done
> wherever appropriate.
>
> yours,
> Jitl
>
>
> On 7/30/2012 6:27 PM, Alia Atlas wrote:
>>
>> Hi James,
>>
>> Thanks for your thoughts.   Streaming (as I've heard) is not as good a
>> description of the desired interface attributes as described in Sec
>> 1.1, the functional overview.
>>
>> IRS is NOT about having interfaces to the forwarding plane.  That's
>> what ForCES is focused on.   This is about communication to a router
>> to install/retrieve routing state into the routing system (FIB, IGPs,
>> BGP, RSVP-TE, etc.)   IRS is NOT splitting the control plane from the
>> router.
>>
>> Are you suggesting that ForCES should drastically expand its scope?
>>
>> Before we start debating what and whether to expand existing
>> protocols, I think we need a common understanding of the problem we're
>> trying to solve and the related framework.
>>
>> Alia
>>
>> On Mon, Jul 30, 2012 at 6:11 PM, James Kempf <[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
>>
>> _______________________________________________
>> irs-discuss mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>