Behcet:

 

The choice between two was because only two protocols groups (IETF protocols at 
that!) suggested they met the requirements.  The call has been made at last 3+ 
meetings. Any new protocol that comes in must prepare as much as Andy Bierman 
did and Jamal Salim did for IETF 89.

 

One other caveat… the protocol will need to make change so the protocol must be 
under the change control of the IETF for I2rs use  Since, ONF has its own 
change control I suspect that also creates a barrier. 

 

Sue 

 

From: Behcet Sarikaya [mailto:sarikaya2...@gmail.com] 
Sent: Friday, April 18, 2014 11:57 AM
To: Susan Hares
Cc: Dean Bogdanovic; i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and model

 

 

 

On Fri, Apr 18, 2014 at 10:42 AM, Susan Hares <sha...@ndzh.com> wrote:

Behcet: 

 

Can you tell me how the ONF Management and configuration protocol will 
interface with the routing system with all the requirements set forth by the 
architecture document?   Please refer to version 2.0 architecture

 

 

Don't get me wrong.

I am not speaking in favor of OF-Config.

But the point is that a more realistic choice should be between these two 
choices.

If the study showed that OF-Config did not meet the requirements, that is fine 
but I heard no one said that.

I wonder if the forces protocol meets these requirements?

 

Behcet 

Or review to the presentation at IETF.   If you can present these features in 
email or any substantial way, we will listen.  In my observations, the ONF 
management protocol was designed for the ONF flows and not the information 
models required or the use case required.   

 

Sue Hares 

 

From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Friday, April 18, 2014 11:32 AM
To: Dean Bogdanovic
Cc: i2rs@ietf.org; Edward Crabbe; Jamal Hadi Salim
Subject: Re: [i2rs] consensus on I2RS protocol and model

 

Hi Dean,

I attended i2rs session in London on this issue.


My question is why ONF Management and Configuration protocol (OF-Config 1.2) 
was not on the table.

Regards,

Behcet 

 

On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic <de...@juniper.net> wrote:

Jamal,

Here are two criteria to be considered:
1. technical
2. commercial/business

We can discuss pros and cons for both, but have to state that from business 
perspective for Juniper going with RESTCONF/YANG make more sense. We already 
built the Junos model in YANG and
have or are in process of building needed tools. Same goes for RESTCONF. We 
have NETCONF implemented in Junos and are working on RESTCONF implementation.
Many carriers adopted or are adopting NETCONF/YANG, are looking into RESTCONF 
as well, so this looks like a low hanging fruit from business perspective.

Looking at technical aspect, unless there is a very compelling reason (and 
there might be, but I'm not aware of it), don't see reason to switch from 
RESTCONF and YANG.
We can find out down the line that RESTCONF/YANG was the wrong way to go, but 
that can be always changed. From my perspective it looks right today.

Just to be clear, I vote for RESTCONF/YANG adoption for i2rs.

Dean


On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim <h...@mojatatu.com> wrote:

> Ok, since nobody is saying anything i'll bite.
> How would you like for this discussion to proceed?
>
> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe <e...@google.com> wrote:
>> Dear I2RSers,
>>
>>  At the last I2RS WG meeting there was a great deal of conversation
>> regarding selection of both modeling language and underlying transport
>> protocol.  Consensus at the time was to make use of Yang and (NetConf or
>> RestConf) (unclear).
>>
>
> And i believe the view, as correctly presented by you, is for folks to go back
> and make educated decisions by actually getting knowledgeable about
> the different views presented. "Consensus" that you described above
> to me looked like  a pageant popularity contest not based on anything
> technical ("who likes contestant in the blue shirt? please cheer for them").
>
> In my opinion i dont think the requirements are clear.
>
> Will that get the crickets stop chirping?
>
> cheers,
> jamal
>
>>  Before coming to a final consensus, we'd like to give people adequate time
>> to review source material, marshall arguments and discuss on the mailing
>> list.  To this end, we're asking that interested parties do just this over
>> the course of the next ~two weeks. Following that period, on 4/28, we'll be
>> initiating a consensus call that will last an additional two weeks, with the
>> aim of converging modeling language / protocol by Friday, 5/9.
>>
>> The consensus call should also generate proposals for any material changes
>> required to the underlying protocols.  These proposals in turn will form the
>> basis for a later draft including gap analysis and said changes.  Those
>> strongly in favor of one protocol over another should be prepared to
>> contribute to this analysis.
>>
>>
>> best,
>>
>>  -ed
>>
>> _______________________________________________
>> i2rs mailing list
>> i2rs@ietf.org
>> https://www.ietf.org/mailman/listinfo/i2rs
>>
>
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
>
>


_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

 

 

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Reply via email to