Re: [irs-discuss] IRS comments

On Fri, Aug 10, 2012 at 5:16 PM, Alia Atlas <akatlas@gmail.com> wrote:
> Scott,
>
> In your example, the control plane would mostly move off the device;
> it still exists.  Dave Meyer asked if IRS would work to communicate
> with routing if it were off the device.  I'd be curious to hear
> people's thoughts on that.  My initial take is that IRS's
> sub-interfaces should be useful regardless - but we need a good use
> case describing that and it would, of course, depend on the
> architectural model that moved the routing off the device.

Noel's comment earlier got me thinking it sure would be nice to rip
out all the routing baggage from ISIS, and just use the flooding
mechanism to discover topology.  And as discussed earlier in other
threads, topology discovery does need to be run on the devices
clearly, so I think we are in agreement here.

>
> I do think it is important to have the RIB as an arbitration mechanism
> on the device.   Russ's suggestion that for the RIB sub-interface, the
> IRS agent might communicate logically to an IRS routing process gives
> good semantics and interactions.  Obviously, implementations may
> differ.

As long as the arbitration mechanism is reconfigurable by the operator
to whatever precedence they want, I agree.  Its not clear to me if
various RIB implementations treat all proffered routes the same, nor
if they store the same meta-data with all protocol sources.  So there
needs to be some way for the operator to leverage exposed
protocol-specific optimizations, without conflict from the other
routing processes, if they so desire.  OTOH if it can all be done via
static routes, it seems much simpler. :)

-Scott

>
> Do you have a particular architectural model that you're thinking of
> for having the control plane off the device?  It's something I've
> talked with various folks about - but have yet to see anything
> convincing written down that addresses most of the issues - from link
> verification and MTU to OAM and resiliency and interactions between
> off-device control-plane controllers/orchestrators.
>
>
> Alia
>
> On Fri, Aug 10, 2012 at 7:22 PM, Scott Whyte <swhyte@google.com> wrote:
>> On Mon, Jul 30, 2012 at 6:40 PM, Gert Grammel <ggrammel@juniper.net> wrote:
>>> Tom,
>>>
>>> It is confusing to understand whether IRS belongs to a new network management plane or if it's more of a control plane extension. The draft wisely avoids this classification.
>>> To me IRS appears to be a completely different beast which should best be  characterized as 'Network Programming Plane' NPP.
>>> It neither aims to do full provisioning (as a management plane would do) nor aims to replace routing (as a control plane would do).
>>
>> Alia's presentation has a diagram with a direct link between the IRS
>> Agent and the RIB Manager; thus it does seem to replace routing.
>>
>>> Hence we better name the baby NPP -- thereby avoiding any linkage to taxation.
>>
>> If none of my switching nodes speak any kind of legacy control plane
>> protocol, yet IRS remains stuffing 500,000 static routes into each
>> (thus programming the network), NPP only makes sense to me if it
>> subsumes the legacy control plane, not co-exists with it as I
>> understand your taxonomy.
>>
>> -Scott
>>
>>>
>>>
>>> Gert
>>>
>>>
>>>
>>>
>>> ----- Original Message -----
>>> From: irs-discuss-bounces@ietf.org <irs-discuss-bounces@ietf.org>
>>> To: Lenny Giuliano; Alia Atlas
>>> Cc: irs-discuss@ietf.org <irs-discuss@ietf.org>
>>> 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" <lenny@juniper.net> 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
>>> irs-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>> _______________________________________________
>>> irs-discuss mailing list
>>> irs-discuss@ietf.org
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>
>>
>>
>> --
>> panem et circenses - a winning strategy for over 2000 years!
>> _______________________________________________
>> irs-discuss mailing list
>> irs-discuss@ietf.org
>> https://www.ietf.org/mailman/listinfo/irs-discuss

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