Re: [i2rs] Mail regarding draft-ietf-i2rs-yang-l3-topology: Modelling of L3 links supported by a L2 broadcast network

[Alia Atlas]

Hi Stephen,

An L2 broadcast network is usually modeled with a pseudo-node and then
separate links between that pseudonode and
each L3 device.  Please take a look at Section B.1.2 where one of the
example ospf-node-attributes is a pseudonode.

Regards,
Alia

On Tue, Oct 22, 2019 at 11:46 PM Stephen Cheng 
wrote:

> Authors of RFC 8346,
>
>
>
> I have a few questions regarding RFC 8346, and would appreciate your
> illumination.
>
>1. Is RFC 8346 ietf-l3-topology intended to cover modelling of L3
>links that is supported by a L2 broadcast network (such as an Ethernet
>network)?
>2. If so, would it be correct to model the L3 connection between every
>pair of L3 device on the L2 broadcast network as a pair of unidirectional
>l3 unicast link ? For example if there are 100 devices on 192.168.1/24
>network, should there be 9900 unidirectional l3 unicast links?
>
> Thanks.
>
>
>
> Warm regards,
>
> Stephen Cheng
>
>
> ___
> 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] AD review of draft-ietf-i2rs-rib-data-model-10

[Alia Atlas]

As is expected, I have done my AD review
of draft-ietf-i2rs-rib-data-model-10. First I would like to thank the
authors - Amit, Lixing, Nitin, Mach, Hari, and Sri - as well as the many
folks who have reviewed and contributed over the years.

I do have some minor comments on details of what is modeled. These are
technical concerns that need to be resolved.  Having communicated the
urgency to Amit already today, I know that he is expecting to be a highly
responsive author during this period.  Therefore, I am requesting IETF Last
Call and placing this on the March 8 IESG telechat.

This document does an excellent job of standardizing the interface to the
RIB, which will have significant impact in the industry over time.

Minor:

1) TTL related comments:  First, the actions for ttl and hop-count should
be aligned. I know of no reason that IPv4 and IPv6 should be different in
this regard to tunnel interactions.  I expect this was just an oversight,
where the ttl-actions increased.  That said, I am dubious about the need
for either decrease-and-copy-to-inner or decrease-and-copy-to-next.   For
the latter,  it isn't typical to modify the label TTL inside during a label
swap. It is during a label pop and then a label push, but that is 2
different actions.  I do not see a need for this action.

identity decrease-and-copy-to-next {
 base "ttl-action";
 description
   "Decrease TTL by one and copy the TTL
to the next header.For example: when
MPLS label swapping, decrease the TTL
of the inner label and copy it to the
outer label.";
   }


2) It would be good to have informative references to GRE, VXLAN, and NVGRE
given in the descriptions.

 identity gre-tunnel {
 base "tunnel-type";
 description
   "GRE tunnel type";
   }

   identity vxlan-tunnel {
 base "tunnel-type";
 description
   "VxLAN tunnel type";
   }

   identity nvgre-tunnel {
 base "tunnel-type";


3) I don't understand the purpose of having an in-label here.  The match
condition is what determines  the in-label.  The label-swap just swaps
whatever is there to the specified out-label. There is no ability to do a
match at this point in the next-hop part - unless you are expecting to
compare the details in the RIB to the route's match-condition when the
next-hop is resolved?  But next-hop resolution isn't per route.  I really
think it just has to be removed - here and earlier in the draft.

  case label-swap {
   container label-swap {
 description
   "Label swap operation.";
 leaf in-label {
   type uint32;
   mandatory true;
   description
 "The label to be swapped.";
 }
 leaf out-label {
   type uint32;
   mandatory true;
   description
 "The out MPLS label.";
 }


4) In the grouping ipv6-header, I see that the next-header field is
specified.  It seems to me that this would depend upon what the match
condition and type of packet was.  One could specify separate next-hops for
each different type of match, of course, but specifying the next-header
field instead of having the router figure it out seems very fragile.  Is
there a strong reason to leave it in?

   leaf next-header {
   type uint8;
   mandatory true;
   description
 "The next header of the IPv6 header.";
 }

5)  "leaf route-preference { type uint32;"  The description should limit
the range of values; as mentioned in the introduction.

6) lookup-limit :  can you explain more in the description what this is
for?  When I see "lookup", I think about the match condition.  Is this a
limit around the levels for resolving next-hops? Is this limiting the
recursion depth on the next-hops?  Is this something else?

Nits:

a) Sec 2.4:  typo "Figure 5 (as shown blow)"  - blow should be "below"

b) typo "Reolved nexthop state" should be "Resolved nexthop state"

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

[Alia Atlas]

Lixing,

I hear that you are concerned.  I still haven't seen your IPR response to
the I2RS mailing list.
Your work is, of course, quite appreciated.

If there is clear justification - that can be sent to the I2RS Chairs and
me, then I am ok with
seeing that and making a call around the authors.

This needs to resolve ASAP.  This is the last draft of i2rs that is not in
IETF Last Call and the
WG is being shut at IETF 101 in 5 weeks.

Regards,
Alia

On Thu, Feb 15, 2018 at 1:04 PM, wang_little_s...@sina.com <
wang_little_s...@sina.com> wrote:

> Hello Alia
> I cann't agree it. I don't stall the process, I just don't give the
> comments. I contributed a lot to this draft.
>
> Best Regards
> Lixing Wang
>
>
>  原始邮件 
> 主题：Re: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
> 发件人：Alia Atlas
> 收件人：wang_little_s...@sina.com
> 抄送：Susan Hares ,Amit Dass ,i2rs@ietf.org,draft-ietf-
> i2rs-rib-data-model@ietf.org
>
>
>
> Lixia,
>
> When an internet-draft is submitted, there is an irrevocable and permanent
> copyright given to the IETF.
> Authors also retain their own copyright, of course.
>
> The draft has 6 authors; there is always a need to justify that.  The IETF
> strongly prefers no more than
> 5 authors.  The fact that you have stalled the process because you did not
> respond to the IPR query
> does not help.
>
> WG Chairs may appoint and replace editors and authors of WG drafts.
>
> Regards,
> Alia
>
> On Thu, Feb 15, 2018 at 12:17 PM, wang_little_s...@sina.com <
> wang_little_s...@sina.com> wrote:
>
>> Hello Susan,
>> I'm the original author of this draft.
>> Even now 70% of this draf is written by me, I have 70% copyright of this
>> draft.
>> So you cann't remove my name.
>>
>> Best Regards
>> Lixing Wang
>>
>> 发自我的华为手机
>>
>>
>>  原始邮件 
>> 主题：RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>> 发件人：Susan Hares
>> 收件人：'Amit Dass' ,'Alia Atlas'
>> 抄送：i2rs@ietf.org,
>>
>>
>>
>> Amit:
>>
>>
>>
>> Remove one of the authors.   Please consider removing LIxing Wang.   I
>> have not received an IPR statement from this person.   Please do this
>> today.   I apologize for the delay in responding.
>>
>>
>>
>> Sue
>>
>>
>>
>> *From:* Amit Dass [mailto:amit.d...@ericsson.com]
>> *Sent:* Monday, February 12, 2018 8:23 AM
>> *To:* Alia Atlas
>> *Cc:* Susan Hares; i2rs@ietf.org; draft-ietf-i2rs-rib-data-model
>> .a...@ietf.org
>> *Subject:* FW: Yangdoctors early review of draft-ietf-i2rs-rib-data-model
>> -09
>>
>>
>>
>> Hi Alia,
>>
>>
>>
>> Apologies for the delay. Needed to redo all again due to the laptop
>> crashed. Updated the draft with the below comments. Couldn’t upload the
>> same due to max 5 author limit kicking in.
>>
>>
>>
>> Best regards,
>>
>> Amit
>>
>>
>>
>> *From:* Alia Atlas [mailto:akat...@gmail.com <akat...@gmail.com>]
>> *Sent:* Saturday, February 10, 2018 1:51 AM
>> *To:* Amit Dass <amit.d...@ericsson.com>
>> *Cc:* Susan Hares <sha...@ndzh.com>; i2rs@ietf.org;
>> draft-ietf-i2rs-rib-data-model@ietf.org
>> *Subject:* Re: Yangdoctors early review of draft-ietf-i2rs-rib-data-model
>> -09
>>
>>
>>
>> Hi Amit,
>>
>>
>>
>> It has been three weeks.
>>
>>
>>
>> Can you please get the update ASAP?  I need to get it reviewed and into
>> IETF Last Call.
>>
>> As you know, I am closing I2RS at IETF 101 - which means this draft needs
>> to be on the March 8 telechat.
>>
>> That means it really should be in IETF Last Call by February 16 - and I
>> am traveling all next week
>>
>> and busy.   I REALLY need it ASAP to review.
>>
>>
>>
>> Regards,
>>
>> Alia
>>
>>
>>
>> On Thu, Jan 18, 2018 at 4:58 AM, Amit Dass <amit.d...@ericsson.com>
>> wrote:
>>
>> Hi Sue,
>>
>> I expect to have some free time during this week.  Should be able to send
>> the update by Monday next week.
>>
>> Best regards,
>> Amit
>>
>> -Original Message-
>>
>> From: Susan Hares [mailto:sha...@ndzh.com]
>> Sent: Thursday, January 18, 2018 10:55 AM
>> To: Amit Dass <amit.d...@ericsson.com>; 'Ebben Aries' <e...@juniper.net>;
>> yang-doct...@ietf.org
>> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
>> i...@iet

Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

[Alia Atlas]

Lixia,

When an internet-draft is submitted, there is an irrevocable and permanent
copyright given to the IETF.
Authors also retain their own copyright, of course.

The draft has 6 authors; there is always a need to justify that.  The IETF
strongly prefers no more than
5 authors.  The fact that you have stalled the process because you did not
respond to the IPR query
does not help.

WG Chairs may appoint and replace editors and authors of WG drafts.

Regards,
Alia

On Thu, Feb 15, 2018 at 12:17 PM, wang_little_s...@sina.com <
wang_little_s...@sina.com> wrote:

> Hello Susan,
> I'm the original author of this draft.
> Even now 70% of this draf is written by me, I have 70% copyright of this
> draft.
> So you cann't remove my name.
>
> Best Regards
> Lixing Wang
>
> 发自我的华为手机
>
>
>  原始邮件 
> 主题：RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
> 发件人：Susan Hares
> 收件人：'Amit Dass' ,'Alia Atlas'
> 抄送：i2rs@ietf.org,
>
>
>
> Amit:
>
>
>
> Remove one of the authors.   Please consider removing LIxing Wang.   I
> have not received an IPR statement from this person.   Please do this
> today.   I apologize for the delay in responding.
>
>
>
> Sue
>
>
>
> *From:* Amit Dass [mailto:amit.d...@ericsson.com]
> *Sent:* Monday, February 12, 2018 8:23 AM
> *To:* Alia Atlas
> *Cc:* Susan Hares; i2rs@ietf.org; draft-ietf-i2rs-rib-data-
> model@ietf.org
> *Subject:* FW: Yangdoctors early review of draft-ietf-i2rs-rib-data-
> model-09
>
>
>
> Hi Alia,
>
>
>
> Apologies for the delay. Needed to redo all again due to the laptop
> crashed. Updated the draft with the below comments. Couldn’t upload the
> same due to max 5 author limit kicking in.
>
>
>
> Best regards,
>
> Amit
>
>
>
> *From:* Alia Atlas [mailto:akat...@gmail.com <akat...@gmail.com>]
> *Sent:* Saturday, February 10, 2018 1:51 AM
> *To:* Amit Dass <amit.d...@ericsson.com>
> *Cc:* Susan Hares <sha...@ndzh.com>; i2rs@ietf.org;
> draft-ietf-i2rs-rib-data-model@ietf.org
> *Subject:* Re: Yangdoctors early review of draft-ietf-i2rs-rib-data-
> model-09
>
>
>
> Hi Amit,
>
>
>
> It has been three weeks.
>
>
>
> Can you please get the update ASAP?  I need to get it reviewed and into
> IETF Last Call.
>
> As you know, I am closing I2RS at IETF 101 - which means this draft needs
> to be on the March 8 telechat.
>
> That means it really should be in IETF Last Call by February 16 - and I am
> traveling all next week
>
> and busy.   I REALLY need it ASAP to review.
>
>
>
> Regards,
>
> Alia
>
>
>
> On Thu, Jan 18, 2018 at 4:58 AM, Amit Dass <amit.d...@ericsson.com> wrote:
>
> Hi Sue,
>
> I expect to have some free time during this week.  Should be able to send
> the update by Monday next week.
>
> Best regards,
> Amit
>
> -Original Message-
>
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, January 18, 2018 10:55 AM
> To: Amit Dass <amit.d...@ericsson.com>; 'Ebben Aries' <e...@juniper.net>;
> yang-doct...@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
> i...@ietf.org
> Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Amit:iir
>
> Do you think you and your co-authors can do this within a few days.   I
> would like to forward the publication request.
>
> Also, please remember to look at the latest Revised datastore draft and
> yang tree module drafts.
>
> Sue Hares
>
> -Original Message-
> From: Amit Dass [mailto:amit.d...@ericsson.com]
> Sent: Thursday, January 18, 2018 4:53 AM
> To: Ebben Aries; yang-doct...@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
> i...@ietf.org
> Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Thanks Ebben for reviewing the draft. I will update the same based on
> below comments and feedback.
>
>
> Best regards,
> Amit
>
> -Original Message-
> From: Ebben Aries [mailto:e...@juniper.net]
> Sent: Thursday, January 18, 2018 9:33 AM
> To: yang-doct...@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
> i...@ietf.org
> Subject: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Reviewer: Ebben Aries
> Review result: On the Right Track
>
> 1 module in this draft:
> - ietf-i2rs-...@2017-12-05.yang
>
> No YANG validation errors or warnings (from pyang 1.7.3 and yanglint
> 0.14.59)
>
> 0 examples are provided in this draft (section 3.12 of
> draft-ietf-netmod-rfc6087bis-15)
>
> Module ietf-i2rs-...@2017-12-05.

Re: [i2rs] AD review of draft-ietf-i2rs-yang-dc-fabric-network-topology-04

[Alia Atlas]

Thank you for the revision.
Given that Geneve is just an example, please have it as an Informative
reference.  Otherwise, this work will not issue as an RFC until Geneve does
and that tight a coupling kids not needed.

Regards,
Alia

On Feb 11, 2018 5:14 AM, "Zhuangyan (Yan)" <zhuangyan.zhu...@huawei.com>
wrote:

> Hi Alia,
>
>
>
> Thank you for your comments~ A new revision has been published to resolve
> your comments.
>
> Detailed responses as below.
>
>
>
> Best Regards,
>
>
>
> Yan
>
>
>
> *From:* Alia Atlas [mailto:akat...@gmail.com]
> *Sent:* Saturday, February 10, 2018 6:28 AM
> *To:* i2rs@ietf.org; draft-ietf-i2rs-yang-dc-fabric-network-topology@ietf.
> org
> *Subject:* AD review of draft-ietf-i2rs-yang-dc-fabric-network-topology-04
>
>
>
> As is customary, I have done my AD review of 
> draft-ietf-i2rs-yang-dc-fabric-network-topology.
> First, I would like to thank the authors - Yan Zhuang, Danian Shi, Rong Gu,
> and Hari Ananthakrishnan - for their excellent and quick work on this
> document.
>
>
>
> I do have a few minor comments below, that can be handled while the
> document is in IETF Last Call - though sooner is better.  When the last
> author responses around IPR notifications are received, Sue will pass this
> to me and I'll put it into IETF Last Call.  I expect it to be on the IEST
> telechat on March 8.
>
>
>
> Minor:
>
>
>
> 1) In the Introduction: " may implement a technique
>  discussed in NVO3 WG, such as GPE [I-D. draft-ietf-nvo3-vxlan-gpe]."
>
>Unless there is a strong motivation for referring to VXLAN-GPE, please
>
>refer to Geneve instead; that is the Standards Track encapsulation that
>
>NVO3 is doing.
>
> Y: Geneve is used instead J.
>
>
>
> 2) Can a device have a role that is both spine and border or both leaf and
> border?
>
>   As defined, I don't see that as possible - but it's just a matter of
> another
>
>  device-role.  Is the assumption that the gateway mode determines whether
>
> border means also spine or also leaf?
>
> Y: Thanks, we corrected the definition of ‘role’. It is now defined as
> “leaf-list” which can include both two identities e.g. leaf and border.
>
> To your question, a spine can be the gateway while a border can be placed
> on a leaf if the network administrator wants…
>
>
>
>  3) leaf traffic-behavior {
> type enumeration {
> enum normal {
> description "Normal";
>
>   What is "Normal"?  Is this shortest-path first?  Or more flexible?  A
> few more words of description
>
> would be helpful.
>
> Y: Added. The normal behavior is that there is no policy enforced to
> traffics…
>
> 4)  container vni-capacity {
>
>  description "Number of vnis that the fabric has";
>
> Could you please expand VNI and provide a reference (Geneve or VXLAN or
> NVO3 Architecture is fine)?
>
> Y: Thank you. Expanded VNI and provided a reference to VXLAN.
>
>
>
> 5)  I don't see [I-D.draft-ietf-nvo3-vxlan-gpe] as a normative
> reference.  Perhaps it is informative - but only mentioned in the
> introduction and I'm suggesting changing to refer to Geneve.
>
>
>
> Y: Geneve is added as a normative reference.
>
>
>
> Nits:
>
>
>
> a)  description "Links that include within a fabric.";  change to "Links
> that are included within the fabric"
>
>
>
> b)  description "Ports that include in the fabric.";  change to "Ports
> that are included within the  fabric"
>
>
>
> c) description "Augmentation for fabric nodes created by faas.";  please
> expand "faas"  It isn't defined or used elsewhere.  Perhaps it is "Fabric
> As A Service"?
>
> Y: yesJ and thank you for the nits.
>
>
>
> Regards,
>
> Alia
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] AD review of draft-ietf-i2rs-rib-info-model-13

[Alia Atlas]

As is customary, I have done my AD review
of draft-ietf-i2rs-rib-info-model-13.  First, I would like to thank the
authors - Nitin, Sri, and Jan - as well as all the reviewers over the years
- and, of course, Sue for her efforts to get this done.

I am delighted to finally see this progressing.  The draft - particularly
the introduction - has gotten even better and clearer.  This is excellent
work.

I have requested an IETF Last Call and placed it on the March 8 telechat.

As you may recall, I step down as Routing AD on March 21 - so it will be
highly desirable to rapidly respond to any comments and issues during the
IESG approval process.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] AD review of draft-ietf-i2rs-yang-dc-fabric-network-topology-04

[Alia Atlas]

As is customary, I have done my AD review of
draft-ietf-i2rs-yang-dc-fabric-network-topology.  First, I would like to
thank the authors - Yan Zhuang, Danian Shi, Rong Gu, and Hari
Ananthakrishnan - for their excellent and quick work on this document.

I do have a few minor comments below, that can be handled while the
document is in IETF Last Call - though sooner is better.  When the last
author responses around IPR notifications are received, Sue will pass this
to me and I'll put it into IETF Last Call.  I expect it to be on the IEST
telechat on March 8.

Minor:

1) In the Introduction: " may implement a technique
 discussed in NVO3 WG, such as GPE [I-D. draft-ietf-nvo3-vxlan-gpe]."
   Unless there is a strong motivation for referring to VXLAN-GPE, please
   refer to Geneve instead; that is the Standards Track encapsulation that
   NVO3 is doing.

2) Can a device have a role that is both spine and border or both leaf and
border?
  As defined, I don't see that as possible - but it's just a matter of
another
 device-role.  Is the assumption that the gateway mode determines whether
  border means also spine or also leaf?

 3) leaf traffic-behavior {
type enumeration {
enum normal {
description "Normal";
  What is "Normal"?  Is this shortest-path first?  Or more flexible?  A few
more words of description
  would be helpful.

4)  container vni-capacity {
 description "Number of vnis that the fabric has";
  Could you please expand VNI and provide a reference (Geneve or VXLAN or
NVO3 Architecture is fine)?

5)  I don't see [I-D.draft-ietf-nvo3-vxlan-gpe] as a normative reference.
Perhaps it is informative - but only mentioned in the introduction and I'm
suggesting changing to refer to Geneve.



Nits:

a)  description "Links that include within a fabric.";  change to "Links
that are included within the fabric"

b)  description "Ports that include in the fabric.";  change to "Ports that
are included within the  fabric"

c) description "Augmentation for fabric nodes created by faas.";  please
expand "faas"  It isn't defined or used elsewhere.  Perhaps it is "Fabric
As A Service"?

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09

[Alia Atlas]

Hi Amit,

It has been three weeks.

Can you please get the update ASAP?  I need to get it reviewed and into
IETF Last Call.
As you know, I am closing I2RS at IETF 101 - which means this draft needs
to be on the March 8 telechat.
That means it really should be in IETF Last Call by February 16 - and I am
traveling all next week
and busy.   I REALLY need it ASAP to review.

Regards,
Alia

On Thu, Jan 18, 2018 at 4:58 AM, Amit Dass  wrote:

> Hi Sue,
>
> I expect to have some free time during this week.  Should be able to send
> the update by Monday next week.
>
> Best regards,
> Amit
>
> -Original Message-
> From: Susan Hares [mailto:sha...@ndzh.com]
> Sent: Thursday, January 18, 2018 10:55 AM
> To: Amit Dass ; 'Ebben Aries' ;
> yang-doct...@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
> i...@ietf.org
> Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Amit:
>
> Do you think you and your co-authors can do this within a few days.   I
> would like to forward the publication request.
>
> Also, please remember to look at the latest Revised datastore draft and
> yang tree module drafts.
>
> Sue Hares
>
> -Original Message-
> From: Amit Dass [mailto:amit.d...@ericsson.com]
> Sent: Thursday, January 18, 2018 4:53 AM
> To: Ebben Aries; yang-doct...@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
> i...@ietf.org
> Subject: RE: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Thanks Ebben for reviewing the draft. I will update the same based on
> below comments and feedback.
>
>
> Best regards,
> Amit
>
> -Original Message-
> From: Ebben Aries [mailto:e...@juniper.net]
> Sent: Thursday, January 18, 2018 9:33 AM
> To: yang-doct...@ietf.org
> Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
> i...@ietf.org
> Subject: Yangdoctors early review of draft-ietf-i2rs-rib-data-model-09
>
> Reviewer: Ebben Aries
> Review result: On the Right Track
>
> 1 module in this draft:
> - ietf-i2rs-...@2017-12-05.yang
>
> No YANG validation errors or warnings (from pyang 1.7.3 and yanglint
> 0.14.59)
>
> 0 examples are provided in this draft (section 3.12 of
> draft-ietf-netmod-rfc6087bis-15)
>
> Module ietf-i2rs-...@2017-12-05.yang:
> - yang-version statement missing - should be 1.1
> - prefix 'iir' is recommended for this module, would 'rib' suffice better?
> - import "ietf-inet-types" should reference RFC 6991 per (not as a comment)
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
> - import "ietf-interfaces" should reference RFC 7223 per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
> - import "ietf-yang-types" should reference RFC 6991 per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-4.7
> - Since this module imports "ietf-interfaces", a normative references must
> be
>   added per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#section-3.9
> - prefix "if" in the import "ietf-interfaces" can remove quotes to remain
>   consistent with other imports
> - Remove WG Chairs from contact information per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Module description must contain most recent copyright notice per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Module description should contain note to RFC Ed. and placeholder
> reference
>   to RFC when assigned
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Add placeholder reference and note to RFC Ed. for RFC when assigned
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-15#appendix-C
> - Security Considerations should be updated to reflect new template at
>   https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines
> - Section 1.2 should be replaced with reference to
>   draft-ietf-netmod-yang-tree-diagrams-02 rather (as-is in other i2rs YANG
>   drafts in progress) per
>   https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-
> 15#section-2.5.1
> - This module contains '12' features.  While it is understood the purpose
> of
>   these features in the module, take precaution as to complexity for
> clients
>   if they need to understand >= quantity of features per module in use on a
>   network-element.
> - A few comments exist that are either unecessary or redundant.  Encode the
>   comment intent rather in description fields if need be.
> - Per NMDA, which datastores are targeted for the module?  Will all RPC
>   operations be acting upon the dynamic/ephemeral datastore?  It is not
> clear
>   to me if the intention is to be persistent or ephemeral
>
> General comments/Nits:
> - references to 'def' could be expanded out to 'definition'
> - references to 'decap' could be expanded out to 'decapsulation' for
>   readability (across definitions and descriptions)
> - Follow 

Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Alia Atlas]

Kent,

>From the 5000 foot view, this looks to me like the description changing the
behavior
of what a system should do.

What am I missing?

Thanks,
Alia

On Fri, Feb 3, 2017 at 1:11 PM, Kent Watsen  wrote:

>
> [Xufeng] Right. If we do so, the approach will be different from RFC7223,
> and requires the capability that a "config true" leafref references a
> "config false" leaf.
>
>
> I think my proposal was misunderstood, so here's a more complete example:
>
> Assume the following schema is used by client/servers that implement the
> long-term
> opstate solution presented in the revised-datastores draft:
>
>module foo {
>   container nodes {
>  config true;
>  list node {
> key "name";
> leaf name { type string; }
> leaf dependency {
>type leafref {
>  path "../node/name"
>  require-instance false;
>  description
>"In the case when a configured node (i.e. in the
> running DS)
> has a dependency on a node that is not configured, the
> system
> may try to resolve the dependency as operational state
> data
> (i.e. in the operational-state DS).  As operational
> state
> data may have a lifecycle independent of
> configuration, there
> is no guarantee that the opstate data will exist.
> Therefore,
> application of the configuration node is conditional,
> resulting
> in an effect much like pre-provisioning interfaces in
> RFC 7223.";
>}
> }
>  }
>  }
>}
>
>
> Specifically, note that the leafref is from one config true node to
> another config
> true node.  I understand that the semantics are almost as if it were like
> a config
> true node were pointing to a config false node, but I believe that this
> should be
> okay, that is, that we should specifically define this convention as okay.
>
>
> Assuming that we're okay with the above, we proposal for a near-term
> solution, that
> does NOT utilize the opstate solution, follows:
>
>module foo {
>   container nodes {
>  config true;
>  list node {
> key "name";
> leaf name { type string; }
> leaf dependency {
>type leafref {
>  path "../node/name"
>  require-instance false;
>  description
>"In the case when a configured node (i.e. in the
> running DS)
> has a dependency on a node that is not configured, the
> system
> may try to resolve the dependency as operational state
> data
> (i.e. under the /nodes-state tree).  As operational
> state
> data may have a lifecycle independent of
> configuration, there
> is no guarantee that the opstate data will exist.
> Therefore,
> application of the configuration node is conditional,
> resulting
> in an effect much like pre-provisioning interfaces in
> RFC 7223.";
>}
> }
>  }
>   }
>   container nodes-state {
>  config false;
>  list node {
> key "name";
> leaf name { type string; }
> leaf dependency {
>type leafref {
>  path "../node/name"
>  require-instance false;
>}
> }
>  }
>   }
>}
>
>
> This module is semantically identical to the first, but now, in additional
> to the leafref potentially hopping datastores, it also needs to hop paths
> (i.e. s/nodes/nodes-state/). Note the minute change in the first sentence
> of the description statement.  Yes, it's a hack, but since the hopping is
> implemented internally anyway, maybe it's okay as a stop-gap short-term
> solution?
>
>
> Kent
>
>
>
> ___
> 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

Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Alia Atlas]

On Wed, Feb 1, 2017 at 3:56 PM, Lou Berger  wrote:

>
>
> On 2/1/2017 2:32 PM, Juergen Schoenwaelder wrote:
> > On Wed, Feb 01, 2017 at 01:52:25PM -0500, Lou Berger wrote:
> >> Juergen,
> >>
> >> What precludes treating such dependencies in the same way
> >> per-provisioning is handled by RFC7223?
> >>
> > This is fine. But having direct dependencies, e.g., leafrefs from
> > config true leafs to config false leafs, is not.
> >
> > /js
> >
>
> Okay, then we're on the same page -- I think some may have missed the
> possibility of handling references to dynamic topology information in
> config using a 'pre-provisioning' approach.
>

I would be happy to see Alex, Xufeng, Kent & Pavan articulate what this
would
look like and how it would work for the base topology model, so that the WG
can
consider all potentially viable options.  I'm not certain how it would
function for the
recursive nature and it does presume the separate /config and /oper-state
trees in
the data-model that were a concern (though certainly the current
recommended
approach for YANG models).

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] Handling technical concerns and progressing topology models

[Alia Atlas]

Dear I2RS Working Group,

There has been significant discussion around draft-ietf-i2rs-yang-
network-topo-10
 as a
side-effect of IESG balloting.  While the focus of the IESG concerns was on
having clearly written security considerations, the active discussion
clearly demonstrated both different perspectives on how the model could be
used and specific technical concerns that were not adequately clear in the
draft or adequately handled to conform with the existing standardized YANG
work.  As a vital part of the IETF process, when there are valid technical
concerns that haven't been addressed, it is necessary to handle them.
Therefore, I am returning both draft-ietf-i2rs-yang-network-topo and
draft-ietf-i2rs-yang-l3-topology-08
 to the
WG.

The specific technical concern is around the model defining a
'server-provided' flag to indicate when configuration (config true) nodes
actually contain and should be treated like operation state (config false)
nodes, which overrides normal YANG behavior.

>From discussions among the authors, NETMOD Chairs, I2RS Chairs, TEAS
Chairs, and myself, the best long-term technical solution continues to be
based upon use of the active work in NetMod that is
draft-ietf-netmod-revised-datastores-00
.
Alex Clemm and Xufeng Liu, with Pavan Beeram's and Kent Watsen's kind
assistance, will be writing the details of the specific issues and
use-cases and proposed solutions to send to the list in the next couple
weeks.

I anticipate that the draft-ietf-i2rs-yang-network-topo will have a new
appendix that will describe the applicability and give examples, based upon
use of the WG-selected solution.  This is for clarity because it is clear
that there are nuances here that are not universally understood in the WG.
Both draft-ietf-i2rs-yang-network-topo and draft-ietf-i2rs-yang-l3-topology
 provide
models that can be generally used. However the details of applicability are
complex for a number of reasons. The model is intended for use by both
routers and controllers.  The data can come from different sources and the
relationships between that data is an important part of that model.  The
particular data domain being modeled has natural complexities.

A key question that I am looking to the WG to answer is what is the
time-criticality of getting these drafts published soon versus when
draft-ietf-netmod-revised-datastores

completes
(which may be a while)?   If urgent, the WG may need to examine short-term
solutions.

Since the initial trigger for this discussion was around the Security
Considerations, I know that Alex will be shortly publishing an updated
draft-ietf-i2rs-yang-network-topo that is based on the existing yang
security considerations recommendations (though updated to reflect multiple
protocols may be used).  Moving forward, as more features are available in
YANG models, I expect those aspects, when used, to also potentially impact
security considerations.

The silence on the list since last week has been due to very active
discussion trying to clarify and articulate the technical concerns and
determine potential solutions.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Alia Atlas]

Juergen,

On Wed, Jan 25, 2017 at 9:52 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Wed, Jan 25, 2017 at 08:35:53AM -0500, Alia Atlas wrote:
> > Could one of you who are saying that a writable topology model can appear
> > in the regular configuration data-store please explain:
> >
> > How does validation at reboot work when there is dependency on learned
> > topology data that isn't yet available?
>
> A configuration datastore never has a dependency on state data.
> Validation is scoped by a datastore. A configuration datastore that is
> valid before a report is going to be valid after a reboot. These are
> core principles of how NETCONF and YANG work.
>
> For the larger picture how information flows from configuration
> datastores to the actual operational state, see the conceptual
> datastore discussions in NETMOD.


Thank you for confirming my understanding.

So - if one has models - such as a writable topology - where there can be
dependencies on dynamic data, then those models can't be in the
configuration
data-store as currently defined.

Regards,
Alia


> /js
>
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103 <http://www.jacobs-university.de/>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Alia Atlas]

Could one of you who are saying that a writable topology model can appear
in the regular configuration data-store please explain:

How does validation at reboot work when there is dependency on learned
topology data that isn't yet available?

I'd prefer more technology discussion of the nuances.  This one has been an
active topic of discussion for at least 2 years, so I'm hopeful that you
all have well thought out answers.

Regards,
Alia

On Wed, Jan 25, 2017 at 7:27 AM, Lou Berger  wrote:

Sue,
>
>>
> In short, I'm going to agree with Benoit - but for slightly different
>
> reasons as I also co-chair TEAS, a group that is basing some of its
>
> work on I2RS developed models.
>
>>
> As a WG chair, I have always viewed the models being developed by I2RS
>
> as typical models that are generally useful, and being defined by I2RS
>
> simply because they were ahead of other groups that might otherwise
>
> define the models -- and I view this as a fine thing that has benefit
>
> for YANG users and other WGs. As TEAS chair, this is what lead me to
>
> ensure that the models being defined in TEAS built on the I2RS YANG
>
> modules vs their original path of redefining parallel function.
>
>>
> As part of my view of the I2RS models being generally applicable to uses
>
> beyond I2RS together with I2RS choosing YANG for modeling ephemeral
>
> data, I have always expected that the I2RS WG would at some (perhaps as
>
> part of the I2RS protocol definition) define how any YANG model can be
>
> used to support I2RS. This view certainly lead me to conclude that
>
> having the I2RS models move forward, just like any other YANG model,
>
> makes sense and would benefit the other models and WGs that reference
>
> this core work. This view also allows for the relationship to the
>
> revised-data store work, as well as the specification of which data
>
> store(s) I2RS uses, to be separately defined -- and to not gate
>
> publication of these models. This separate specification would be
>
> the location for any I2RS-specific transport and security considers,
>
> so such would not belong in the generally reusable models developed
>
> by I2RS.
>
>>
> Essentially, As NETMOD co-chair, I concluded that the revised data
>
> store work provided the direction on how ephemeral would be supported
>
> in a general YANG context and, therefore, the major open issue / gating
>
> impediment to progressing I2RS models had been removed and publication
>
> of these models were unblocked. This also motivated my comments in the
>
> related discussions at the last meeting.
>
>>
> If my understanding/view is correct, i.e., that the topology models are
>
> just like any other YANG model, then I think publication can and
>
> should proceed (with the appropriate text for a typical YANG model). If
>
> I misunderstood something, and the models produced by I2RS are limited
>
> to ephemeral representations/data stores as well as specific YANG
>
> transport protocols -- then as TEAS chair, I have to hit reset on the
>
> TEAS topology work, and as NETMOD chair I think the NETMOD WG needs to
>
> discuss what it means for a YANG model to be protocol/datastore
>
> specific and if any guidelines or other new NTEMOD documents are need
>
> to support such.
>
>>
> Less importantly, as I2RS participant, I'd also ask for the documents
>
> to be sent back to the WG for a new last call once the documents
>
> are updated to reflect their narrow scope -- as I bet I'm not the only
>
> person who viewed this work applicable to non-ephemeral uses.
>
>>
> I hope this helps.
>
>>
> Lou
>
>
> On January 24, 2017 11:56:32 AM "Susan Hares"  wrote:
>
> > To: Martin:
> >
> > You have a reasonable request. If the NETMOD WG Chairs confirm their
> > decision to make I2RS Yang Modules part of the Control Plane Datastore
> then
> > as shepherd/WG-chair I will recommend these get added to the draft.
> >
> > Note to authors :
> >
> > As we wait for the NETMOD WG Chairs and Benoit to deliver the decision on
> > Config/Control Plane datastore, the authors should work on:  Basic Yang
> > security considerations and the other I2RS Yang Module information.
> >
> > Sue Hares (Shepherd)
> > -Original Message-
> > From: Martin Bjorklund [mailto:m...@tail-f.com]
> > Sent: Tuesday, January 24, 2017 10:39 AM
> > To: sha...@ndzh.com
> > Cc: i2rs@ietf.org; draft-ietf-i2rs-yang-l3-topol...@ietf.org;
> > j.schoenwael...@jacobs-university.de; i2rs-cha...@ietf.org; n...@hq.sk;
> > kathleen.moriarty.i...@gmail.com; i...@ietf.org; lber...@labn.net;
> > kwat...@juniper.net
> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> > draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> >
> > "Susan Hares"  wrote:
> >> Martin:
> >>
> >>
> >>
> >> I'm sorry if misunderstood your comments regarding the
> >> draft-ietf-netmod-revised-datastores-00.txt.  The reason the answer is
> >> unclear is that it depends on the context of the question.
> >>
> >>

Re: [i2rs] Kathleen Moriarty's No Objection on draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)

[Alia Atlas]

Tom,

Let me be absolutely clear - and this is not just directed at you,
obviously.

The IESG shares the various balloting positions for transparency.
They are supposed to be handling specific technical concerns and objections.

I am extremely disappointed in the quality of the discussion, the efforts
to reopen
topics that have been closed and approved for publication, and the shocking
and
appalling unwillingness to listen or discuss the actual issues involved.

I2RS uses feature extensions that were not available in basic YANG and
NetConf.
Those features are used in I2RS models.   Unsurprisingly, this can and does
carry
security implications depending on the details of the feature.

IF several of you have not been thinking through the implications of the
work, it
is not for lack of effort on the part of the I2RS WG or its chairs, in the
past and present.

It would be fascinating to see conversation delving into the technical
questions instead
of trying to assert how things should be without doing the detailed work of
understanding
the implications.

I have excellent technical conversations with most of you across many years.

I am extremely disappointed.

Alia

On Tue, Jan 24, 2017 at 7:16 PM, Thomas Nadeau 
wrote:

>
> Please refer to what Benoit just said.
>
> —Tom
>
>
> > On Jan 24, 2017:7:10 PM, at 7:10 PM, Susan Hares 
> wrote:
> >
> > Tom:
> >
> > Unclear what you are saying.
> >
> > Sue
> >
> > -Original Message-
> > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Thomas Nadeau
> > Sent: Tuesday, January 24, 2017 3:02 PM
> > To: Susan Hares
> > Cc: i2rs@ietf.org; Anton Ivanov
> > Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> >
> >
> >   Sue:
> >
> >   The implication of that statement is that actual implementations
> (like ODL etc) now need to copy/paste this model without the I2RS text to
> use them in other ways. This seems strange and just about the most
> inefficient way to use these that I can think of.
> >
> >   —Tom
> >
> >
> >
> >> On Jan 24, 2017:12:50 PM, at 12:50 PM, Susan Hares 
> wrote:
> >>
> >> Anton:
> >>
> >> See earlier message to Martin.  Topology models are I2RS YANG Models
> >> designed for ephemeral state with specific security concerns.  This is
> >> not your basic YANG model no matter which data store ephemeral gets
> linked to.
> >> Where is ephemeral state?  By IESG Design of charter, I2RS is not in
> >> charge of defining ephemeral state solution.  NETMOD/NETCONF are.  Go
> ask them.
> >>
> >> Do not blame the messenger echoing NETMOD results,
> >>
> >> Sue
> >>
> >> -Original Message-
> >> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Anton Ivanov
> >> Sent: Tuesday, January 24, 2017 8:30 AM
> >> To: i2rs@ietf.org
> >> Subject: Re: [i2rs] Kathleen Moriarty's No Objection on
> >> draft-ietf-i2rs-yang-l3-topology-08: (with COMMENT)
> >>
> >> On 24/01/17 11:52, Juergen Schoenwaelder wrote:
> >>> Susan,
> >>>
> >>> so are these YANG models regular YANG models or are these YANG models
> >>> specific to the yet to be defined I2RS protocol and yet to be defined
> >>> datastores?
> >>>
> >>> I think this is the core of Martin's and my question. A simple clear
> >>> and concise answer would be nice.
> >>
> >> +1.
> >>
> >> A.
> >>
> >>
> >> ___
> >> 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
>
> ___
> 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

Re: [i2rs] FW: Genart LC review: draft-ietf-i2rs-yang-network-topo-09

[Alia Atlas]

On Thu, Jan 5, 2017 at 7:52 AM, Jari Arkko  wrote:

> Seems like you got it now. I don’t think we should worry about the 6
> authors at the moment. But do look at the rest.


I did, of course, verify that all the authors are and have been actively
involved and contributed significantly.

Regards,
Alia



> Jari
>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] AD review of draft-i2rs-yang-l3-topology-06

[Alia Atlas]

(correcting typo  to send to draft authors)

On Tue, Dec 6, 2016 at 10:28 AM, Alia Atlas <akat...@gmail.com> wrote:

> As is customary, I have done my AD review of draft-i2rs-yang-l3-topology-06
> before progressing it to IETF Last Call.
>
> First, I would like to thank the authors and contributors of this document
> for their work.
>
> Regrettably, I will not progress this document with 9 authors (one of
> whose email already bounces).  Please select a few editors and update it.
> I have scheduled this for the January 5, 2017 telechat - which means that
> it must be ready for IETF Last Call no later than Dec 13 & preferrably
> sooner, given the end-of-year vacations typical.
>
> Please find my detailed review below.
>
> Major:
>
> a) Please clarify whether there are existing WG models that depend on this
> module.
>
> b) "augment /nd:networks/nd:network/nd:node/lnk:termination-point:
>
>   +--rw l3-termination-point-attributes
>  +--rw (termination-point-type)?
> +--:(ip)
> |  +--rw ip-address*  inet:ip-address
> +--:(unnumbered)
>+--rw unnumbered-id?   uint32 "
> Is the unnumbered-id an ifIndex?  Can you declare it with that type?
> Similarly in the model on p. 12:
> "case unnumbered {
>
>  leaf unnumbered-id {
>type uint32;
>description
>  "Unnumbered interface identifier";
>  }"
> why isn't this an ifIndex?!?
>
> Minor:
>
> 1) Intro: Please clean up paragraphs 2&3.   When this is an RFC, it wont
> matter what the logic was for pulling the L3 topology model out. That can
> go.  Similarly, there are existing WG drafts for IS-IS and OSPF models.
> Rather than "expecting", how about a reference?  Are there such models?
>
> 2) Intro:  Do we really need the paragraph on why to choose YANG?
>
> 3)Intro:  How about an informative reference to the TED topology model?
>
> 4) Sec 2: Datastore definition -  please add a pointer to the NetMod RFC
> that defines it or at least indicate that this isn't a new definition &
> where it comes from.
>
> 5) On p. 9:  " typedef link-flag-type {
>
>type identityref {
>  base "flag-identity";
>}
>description "Prefix flag attributes";  "
> Shouldn't the description be "Link flag attributes"?
>
> 6)  Section 6 with the non-normative examples should be an Appendix.
>
> 7)  Contributors should be listed with at most address information (which
> usually includes affiliation) - but such affiliation should be
> correct!(e.g. Ken Gray) or just by name.  We are all participating as
> individuals - not company representatives.
>
> Regards,
> Alia
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] AD review of draft-i2rs-yang-l3-topology-06

[Alia Atlas]

As is customary, I have done my AD review of draft-i2rs-yang-l3-topology-06
before progressing it to IETF Last Call.

First, I would like to thank the authors and contributors of this document
for their work.

Regrettably, I will not progress this document with 9 authors (one of
whose email already bounces).  Please select a few editors and update it.
I have scheduled this for the January 5, 2017 telechat - which means that
it must be ready for IETF Last Call no later than Dec 13 & preferrably
sooner, given the end-of-year vacations typical.

Please find my detailed review below.

Major:

a) Please clarify whether there are existing WG models that depend on this
module.

b) "augment /nd:networks/nd:network/nd:node/lnk:termination-point:

  +--rw l3-termination-point-attributes
 +--rw (termination-point-type)?
+--:(ip)
|  +--rw ip-address*  inet:ip-address
+--:(unnumbered)
   +--rw unnumbered-id?   uint32 "
Is the unnumbered-id an ifIndex?  Can you declare it with that type?
Similarly in the model on p. 12:
"case unnumbered {

 leaf unnumbered-id {
   type uint32;
   description
 "Unnumbered interface identifier";
 }"
why isn't this an ifIndex?!?

Minor:

1) Intro: Please clean up paragraphs 2&3.   When this is an RFC, it wont
matter what the logic was for pulling the L3 topology model out. That can
go.  Similarly, there are existing WG drafts for IS-IS and OSPF models.
Rather than "expecting", how about a reference?  Are there such models?

2) Intro:  Do we really need the paragraph on why to choose YANG?

3)Intro:  How about an informative reference to the TED topology model?

4) Sec 2: Datastore definition -  please add a pointer to the NetMod RFC
that defines it or at least indicate that this isn't a new definition &
where it comes from.

5) On p. 9:  " typedef link-flag-type {

   type identityref {
 base "flag-identity";
   }
   description "Prefix flag attributes";  "
Shouldn't the description be "Link flag attributes"?

6)  Section 6 with the non-normative examples should be an Appendix.

7)  Contributors should be listed with at most address information (which
usually includes affiliation) - but such affiliation should be
correct!(e.g. Ken Gray) or just by name.  We are all participating as
individuals - not company representatives.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] AD review of draft-ietf-i2rs-yang-network-topo

[Alia Atlas]

As is customary, I have done my AD review
of draft-ietf-i2rs-yang-network-topo-09.  First I would like to thank the
authors, Alex, Jan, Hari, Nitin, Robert, & Xufeng, for their work on a very
nicely written document.

I do see that there are 6 authors.  I am open to hearing why and how each
author has and will continue to be an active participant - including
through AUTH48, but this is higher than the normal limit.

I am requesting that IETF Last Call start and have scheduled this for the
IESG telechat on Jan 5, 2017.

I do have a few minor comments below:

1) Section 5 mentions I-D.draft-acee-rtgwg-yang-rib-extend.  Since this is
an individual draft, it's probably better not to include it as a reference.

2) On p. 25-26, in list link description:  "Layering dependencies on links
in underlay topologies are
  not represented, as the layering information of nodes and of
  termination points is sufficient."  This seems to contradict
earlier text and the exice of the list supporting link that is immediately
after.  Could you please clean up or clarify?

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] AD review of draft-ietf-i2rs-ephemeral-state-18

[Alia Atlas]

Sue,

This looks good - thanks.  I will put it into IETF Last Call.

Regards,
Alia

On Wed, Oct 5, 2016 at 9:19 AM, Susan Hares <sha...@ndzh.com> wrote:

> Alia:
>
>
>
> I’ve updated version 19 with the changes. The only change I did not
> implement was to combine section 5 and 6.   The NETCONF group asked us not
> to combine these two sections.  I left these two sections intact.   Does
> this work for you?
>
>
>
>
>
> Sue
>
>
>
> *From:* Alia Atlas [mailto:akat...@gmail.com]
> *Sent:* Tuesday, October 4, 2016 10:37 PM
> *To:* i2rs@ietf.org; draft-ietf-i2rs-ephemeral-st...@ietf.org
> *Subject:* AD review of draft-ietf-i2rs-ephemeral-state-18
>
>
>
> Hi,
>
>
>
> As is customary, I have done my AD review of 
> draft-ietf-i2rs-ephemeral-state-18.
> First, I would like to thank Sue and Jeff for their hard work pulling this
> document together in an effort to add clarity to the requirements.
>
>
>
> I do have a number of comments - many relatively minor.  Assuming a fast
> turn-around, as usual from I2RS, we should be able to have this on the Oct
> 27 telechat - which will mean it needs to enter IETF Last Call before the
> end of this week.
>
>
>
> Here is my review:
>
>
>
> Major:
>
>
>
> 1) Ephemeral-REQ-12:  This specifies that a notification be sent to the
>
> original client, regardless of whether it won or lost the priority
> collision.
>
> I had assumed that the notification would go to either the requesting
> client
>
> or the original client depending on which one lost the priority comparison.
>
> I have some concerns about an indirect flood of notifications caused by a
>
> requesting client that has the lower priority.  Regardless, clarifying that
>
> the lower-priority client is notified is important.
>
>
>
>
>
>
>
> Minor:
>
> a) Intro: Remove "3 suggest protocol strawman" as something that
>
>the I2RS requirements must do.  I know that is how the process
>
>has been working out - but it isn't dictated by the technology
>
>at all - as the other 2 are.  Similarly, replace the following
>
>paragraph "The purpose of these requirements and the suggested
>
>protocol strawman is to provide a quick turnaround on creating
>
>the I2RS protocol." with something like "The purpose of these
>
>requirements is to ensure clarity during I2RS protocol creation."
>
>
>
> b) Section 2:  "The following are ten requirements that [RFC7921]
>
>contains which provide context for the ephemeral data state
>
>requirements given in sections 3-8:"
>
>   How about "The following are requirements distilled from [RFC7921]
>
>  that provide context for..."
>
>
>
> 1)  Not relevant for ephemeral - this matters for pub/sub (suggest
> removal)
>
> 2)  Relevant for ephemeral b/c of vague performance requirements on
>
> possible solutions.
>
> 3)  What changes if the data model is protocol dependent?  Is this
> just that
>
> the model may be an augmentation/extension of an existing module?
>
> 4)  Absolutely - keep
>
> 5)  Absolutely - keep
>
> 6)  Remove - not relevant for ephemeral just security requirements
>
> 7)  Remove - not relevant for ephemeral just security requirements
>
> 8)  Absolutely - keep (but says storing secondary identity on deletion
> when
>
> that isn't mentioned for (4) b/c it's about priority - so clarify
> slightly)
>
> 9)  Absolutely - keep
>
>10)  Remove - not relevant for ephemeral
>
>
>
> c) Sec 3.3 bullet 2:  This refers to YANG data model instead of YANG
> module as
>
>in bullet 1.  If there's a reason for the difference, please clarify
> and otherwise
>
>make consistent.
>
>
>
> d) Sec 5 & 6 for NETCONF and RESTCONF are the same requirements.  Please
>
> consolidate into a section of "The changes to NETCONF and the conceptual
> changes to RESTCONF are"
>
>
>
> e) Sec 8:  I found this pull-out unclear.  "multiple operations in one
>
>   or more messages; though errors in
>
>   message or operation will have no effect on other messages or
>
>   commands even they are related."
>
>
>
>  I think you mean "Multiple operations in one message can be sent.
> However
>
>  an error in one operation MUST NOT stop additional operations from
> being
>
>  carried out nor can it cause previous operations in the same message
> to
>
>  be rolled back."
>
>
>
> Nits:
>
>
>
> i) Abstract: "attempting to meet I2RS needs has to provide"/
>
> "attempting to meet the needs of I2RS has to provide"
>
>
>
> ii) 3.2: "MPLS LSP-ID or BGP IN-RIB"  please expand acronyms
>
>
>
> iii) Sec 5 last sentence:  Either missing a ( or has an unneeded ).
>
>
>
> iv) Ephemeral-REQ-11:  "I2RS Protocol I2RS Protocol" repeated
>
>
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Kathleen Moriarty's Discuss on draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and COMMENT)

[Alia Atlas]

First, to be very clear.  This document has WG consensus - confirmed over
multiple WGLCs - in the I2RS WG.
This thread is to resolve the concerns expressed by the ADs about specific
aspects of this document.

Second, by having a requirement for indicating in the model - whether for
the whole model or per leaf - that
the data may be sent over an insecure transport, this encourages limiting
the standard use of an insecure
transport to exactly those models or data that requires it for a given
use-case.

I do see this as limited to certain types of use-cases and the ability to
mount a model differently allows the
flexibility of describing a particular model as acceptable for insecure
transport rather than requiring a leaf-by-leaf
indication.

The use of insecure transport is to accommodate use-cases that were not in
the scope initially considered
for NetConf/RestConf.

Regards,
Alia

On Fri, Aug 19, 2016 at 12:32 PM, Andy Bierman  wrote:

>
>
> On Fri, Aug 19, 2016 at 8:42 AM, Susan Hares  wrote:
>
>> Andy:
>>
>>
>>
>> I have been thinking about your question for 30 minutes.   Let me put
>> down a few of my personal opinions:
>>
>>
>>
>> 1)  Most (99%) of the ephemeral data models will not allow
>> non-secure transport.
>>
>> 2)   If any ephemeral data models have an insecure section, the
>> review and consensus for a standards model should take longer.
>>
>> I hope we can streamline the normal Yang model review.  [It would be nice
>> to streamline features additions for NETCONF/RESTCONF as well].
>>
>>
>>
>
> I hope you are right that it will almost always be easy for a WG
> to decide this issue for each leaf.
>
> We already have "security tagging" in NACM, and this has not caused delays.
> This is the opposite decision -- Is this data so sensitive that the NACM
> default
> access control needs to block writes (nacm:default-deny-write) or block
> all access
> (nacm:default-deny-all)?
>
> These extensions are used in ietf-system.yang, not just in the NACM RFC.
> They can be used anywhere and a NACM implementation MUST enforce
> the extension semantics.
>
> If YANG Push had similar requirements (i.e, MUST NOT send data in the clear
> that is not tagged with the appropriate extension) and the review criteria
> is clear,
> then this approach should be OK.
>
>
> Andy
>
>
> 3)  I prefer to have the non-secure sections of a data model moved to
>> a separate date model, and the data model marked as insecure.
>>
>> [I do not know if we could use the library function to mark the data
>> model in meta-language.]
>>
>> However, until we complete the mount schema work – I do not know if this
>> is workable.
>>
>>
>>
>> Would it help if I changed version -08 to
>>
>> Old/
>>
>>A non-secure transport can be used for publishing telemetry data or
>>
>>other operational state that was specifically indicated to non-
>>
>>confidential in the data model in the Yang syntax. /
>>
>> New:/
>>
>>   A non-secure transport can be used for publishing telemetry data or
>> other
>>
>>  Operational state that was specifically indicated to be
>> non-confidential in the data model.
>>
>> /
>>
>>
>>
>> Sue
>>
>>
>>
>>
>>
>> *From:* i2rs [mailto:i2rs-boun...@ietf.org] *On Behalf Of *Susan Hares
>> *Sent:* Friday, August 19, 2016 10:59 AM
>> *To:* 'Andy Bierman'; 'Lou Berger'
>> *Cc:* i2rs@ietf.org; 'Alissa Cooper'; 'Juergen Schoenwaelder';
>> i2rs-cha...@ietf.org; 'Kathleen Moriarty'; 'IESG'; 'Jeffrey Haas'; 'Joel
>> Halpern'; draft-ietf-i2rs-protocol-security-requireme...@ietf.org
>> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
>> COMMENT)
>>
>>
>>
>> Andy:
>>
>>
>>
>> Thank you for your comments.   Perhaps you can provide for the IESG the
>> list of things that are needed to move a Yang module forward in the IETF.
>>
>>
>>
>> Sue
>>
>>
>>
>> *From:* Andy Bierman [mailto:a...@yumaworks.com ]
>> *Sent:* Friday, August 19, 2016 10:24 AM
>> *To:* Lou Berger
>> *Cc:* Susan Hares; Juergen Schoenwaelder; i2rs@ietf.org; Alissa Cooper;
>> i2rs-cha...@ietf.org; Kathleen Moriarty; IESG; Jeffrey Haas; Joel
>> Halpern; draft-ietf-i2rs-protocol-security-requireme...@ietf.org
>> *Subject:* Re: [i2rs] Kathleen Moriarty's Discuss on
>> draft-ietf-i2rs-protocol-security-requirements-07: (with DISCUSS and
>> COMMENT)
>>
>>
>>
>> Hi,
>>
>>
>>
>> I agree with Juergen.
>>
>> There are already too many details that need consensus to move
>>
>> a YANG module forward in the IETF.  It takes too long already.
>>
>>
>>
>> We could have been tagging MIB objects all along, but we don't.
>>
>> Imagine if there was a debate for every single OBJECT-TYPE macro
>>
>> "is this leaf OK for noAuth/noPriv?"
>>
>>
>>
>> Are there even clear SEC-DIR guidelines on how one would decide this
>>
>> debate in a WG? Does SEC-DIR really want to be flooded with review
>>
>> requests so they become a bottleneck in YANG 

Re: [i2rs] Mirja Kühlewind's No Objection on draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)

[Alia Atlas]

Hi Mirja,
On Fri, Aug 19, 2016 at 2:54 PM, Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:

> Hi Sue,
>
> thanks for addressing my comments!
>
> The only remaining one is if this doc should be published as an own RFC or
> merged with the other requirement documents. I mainly wanted to raise this
> point for discussion and will leave the decision to the responsible AD.


It needs to progress on its own.

Thanks,
Alia



> Mirja
>
>
> > Am 19.08.2016 um 20:15 schrieb Susan Hares :
> >
> > Mirja:
> >
> > Thank you for your reply.  I have removed the text regarding RFC4949.  I
> believe version-08.txt resolves these comments.
> >
> > Sue
> >
> > -Original Message-
> > From: Mirja Kuehlewind (IETF) [mailto:i...@kuehlewind.net]
> > Sent: Friday, August 19, 2016 1:30 PM
> > To: Susan Hares
> > Cc: The IESG; jh...@pfrc.org; i2rs@ietf.org; i2rs-cha...@ietf.org;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> > Subject: Re: [i2rs] Mirja Kühlewind's No Objection on
> draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)
> >
> > Hi Sue,
> >
> > thanks for you replies and background information. Please see further
> below.
> >
> > Mirja
> >
> >> Am 18.08.2016 um 02:15 schrieb Susan Hares :
> >>
> >> Mirja:
> >>
> >> Thank you for the review.  Please see the comments below.Your
> comments are sensible, but the sections were put in place to provide
> background for the multiple working groups utilizing these requirements.
> Please let me know if I can answer additional questions.
> >>
> >> Sue Hares
> >>
> >> -Original Message-
> >> From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Mirja Kuehlewind
> >> Sent: Wednesday, August 17, 2016 4:37 AM
> >> To: The IESG
> >> Cc: jh...@pfrc.org; i2rs@ietf.org; i2rs-cha...@ietf.org;
> draft-ietf-i2rs-protocol-security-requireme...@ietf.org
> >> Subject: [i2rs] Mirja Kühlewind's No Objection on
> draft-ietf-i2rs-protocol-security-requirements-06: (with COMMENT)
> >>
> >> Mirja Kühlewind has entered the following ballot position for
> >> draft-ietf-i2rs-protocol-security-requirements-06: No Objection
> >>
> >> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> >>
> >>
> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.
> html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >>
> >>
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-i2rs-protocol-
> security-requirements/
> >>
> >>
> >>
> >> --
> >> COMMENT:
> >>> --
> >>>
> >>> A few comments:
> >>>
> >>> 1) I don't think copy from RFC4949 is necessary. I would
> recommend to remove this part and just name the definitions that are needed.
> >>>
> >>> Sue: Initially, the WG and the authors ran into problems with security
> words.  We included definitions that seem to resolve issues for the WG and
> those who will need to >implemented in NETCONF/RESTCONF.
> >
> >> I understand that this helped the writing process and discussion in the
> working group. However, I still advise to remove this from the final RFC
> given that readers can easily >check the referred RFC if needed and this
> avoids text duplications (which e.g. makes updates very hard).
> >
> > Sue: I removed the RFC4949 cut and paste in version -08.txt.   Can I
> consider this item closed?
> >
> >>>
> >>> 2) The following sentence seems to indicate that the refernce to
> RFC4949 should be normative.
> >>> "The transfer of data via the I2RS protocol has the property of data
> integrity described in [RFC4949]."
> >>> As I don't think this is needed, I would recommend to rather spell out
> the properties here in this sentence. Also, to be honstest I not sure what
> this sentence tells me at all.
> >>> So maybe stating clearing what you mean (instead of just having the
> reference) would help anyway.
> >>>
> >>> Sue: I have moved RFC4949 to normative.   RFC4949 states data
> integrity means: a) data has not been changed, destroyed or lost in an
> unauthorized (or accidental) manner,
> >>> and b) the information has not been modified or destroyed in an
> unauthorized manner.   This statement covers man-in-the middle attacks or
> unauthorized changes.
> >
> >> Okay. I would still recommend to spell this simply out in the draft
> instead of just giving the reference.
> >
> > Sue: I removed this text.
> >
> >>> 3) To me it's not really clear why there are several requirments docs
> (that also are connected and refer each other; see e.g. section 3.6 and
> SEC-REQ-16).
> >> The actually context of this doc is only 4 pages (3.1-3.6). Couldn't
> those docs be combined to one requirements doc?
> >>
> >> Sue: This is a good 

Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs. ephemeral)

[Alia Atlas]

LGTM

On Jul 20, 2016 5:15 PM, "Susan Hares"  wrote:

> Works for me!
>
> Sue
>
> -Original Message-
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> Sent: Wednesday, July 20, 2016 8:56 AM
> To: Joe Clarke; Susan Hares; 'Russ White'; i2rs@ietf.org
> Subject: Re: [i2rs] Comments on Ephemeral-REQ-07 (local config vs.
> ephemeral)
>
> That text works for me.
> Thanks,
> Joel
>
> On 7/20/16 8:52 AM, Joe Clarke wrote:
> > On 7/20/16 07:59, Juergen Schoenwaelder wrote:
> >> The text I comment to says "individual ephemeral configuration
> >> changes" - I was not able to infer from this that it was supposed to
> >> imply "individual I2RS clients".
> >
> > I agree with both you and Joel.  "Individual" should apply to clients,
> > but we need to have something that ties priority to local config.
> >
> > What about:
> >
> > Req-07: Local configuration MUST have a priority that is comparable
> > with individual I2RS client priorities for making changes.  This
> > priority will determine whether local configuration changes or
> > individual ephemeral configuration changes take precedence as described
> in
> RFC7921.
> >  The I2RS protocol MUST support his mechanism.
> >
> > Joe
> >
>
> ___
> 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] new I2RS chair: Russ White replacing Jeff Haas

[Alia Atlas]

I would like to announce that Russ White is replacing Jeff Haas
as I2RS Chair.  I would like to thank Jeff for his efforts over the
years in helping I2RS progress.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] RtgDir review: draft-ietf-i2rs-pub-sub-requirements-06

[Alia Atlas]

Hi Dan,

Thank you very much for your review.  This document is intended to be
Informational; the data-tracker needed to be updated.
I do have a few comments in-line.

Eric, Alex, Gonzalez & Sue, please address these comments ASAP as you feel
is appropriate.
I do think that some clarifications will help.
I do think that version 06 is quite improved in sections 1 & 2.


On Mon, Apr 25, 2016 at 12:04 PM, Dan Frost  wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this
> draft. The Routing Directorate seeks to review all routing or
> routing-related drafts as they pass through IETF last call and IESG
> review, and sometimes on special request. The purpose of the review is
> to provide assistance to the Routing ADs. For more information about the
> Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF
> Last Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-i2rs-pub-sub-requirements-06
> Reviewer: Dan Frost
> Review Date: 2016-04-25
> IETF LC End Date: 2016-04-29
> Intended Status: Informational (?)
>
> Summary:
>
> I have significant concerns about this document and recommend that the
> Routing ADs discuss these issues further with the authors.
>
> Comments:
>
> Overall this is a clear and consistent requirements document that
> addresses an important real-world problem domain, and is nearly ready
> for publication.  However, because this work may lead to significant
> changes in the mechanics of network management and control, some extra
> care in the review stage is warranted.  I've marked some issues as major
> to indicate that they may deserve extra consideration by the ADs and/or
> the wider Internet community.
>
>
> Major Issues:
>
> 1. There seems to be some confusion as to the intended status of the
> document.  The draft itself lists its intended status as Informational,
> which is usually appropriate for a requirements document.  On the other
> hand, the draft was submitted to the IESG with an Intended Status of
> Proposed Standard.  Furthermore, a quick check of other I2RS WG
> requirements docs shows them split between Informational and Proposed
> Standard, so the confusion may extend beyond this draft.  I'd suggest
> the ADs and chairs agree on a consistent policy.
>

[Alia] Good catch.  Agreement is that they are informational.



> 2. The document concerns requirements for a publish/subscribe interface
> to, among other things, real-time operational data.  The text in Section
> 2.3 indicates an awareness of the need to support potentially large
> numbers of subscribers and high volumes of data.  However, the document
> doesn't seem to discuss the global network impact of continuously
> pushing a lot of data to many subscribers.
>
> As the introduction of such a push system could lead to a qualitative
> shift in the total volume of management/control traffic, it seems
> important to begin addressing this issue at the requirements stage.
>
> A possible resolution would be to add a brief section on network impact
> under large-scale conditions, and/or a set of requirements for
> minimizing this impact.  Some of the listed requirements are germane to
> this, e.g. subscription filters. bundling, and dampening.  Issues that
> are not addressed include support for encoding formats that are
> efficient for high-volume transport and processing (XML and JSON are
> usually considered not to be); appropriate selection of transport
> protocols and features according to scale/use-case; and support for
> mechanisms to determine or restrict the bandwidth cost of a proposed or
> ongoing subscription.
>

[Alia] There are a number of different potential transports and encodings;
these tend
to be dictated by the ecosystem in which the deployment is desired.  These
I2RS requirements are targeted initially for YANG with NetConf and RestConf.
An expectation is that the mechanisms such as subscription filters,
bundling,
and dampening, can be reused for other transports and encodings.

3. This work is being carried out in the I2RS WG, but the first sentence
> of Section 2.2 states that this document is intended to cover
> requirements beyond I2RS.  A general question for the editors/chairs/ADs
> is whether it has received any review by interested/affected parties
> outside I2RS?
>

[Alia] A proposed solution is being discussed in NetConf.


> 4. The Security Requirements make no mention of data integrity or
> confidentiality.  This is a potentially serious omission in today's
> network environment.  I would expect at the least that subscribers have
> the ability to request a secure (authenticated, integrity-verified,
> confidential) session, that publishers likewise have the ability to
> refuse non-secure sessions, 

Re: [i2rs] RtgDir review: draft-ietf-i2rs-traceability-08

[Alia Atlas]

Les,

Thank you very much for your review.

Joe,
Thanks for following up.  I'll get this on the IESG telechat for next Thurs.


Regards,
Alia



On Fri, Apr 29, 2016 at 1:43 PM, Joe Clarke  wrote:

> On 4/27/16 17:39, Les Ginsberg (ginsberg) wrote:
>
>> Summary:  This document is a well written document - easy to understand.
>> My compliments to the authors. I believe there is one minor issue which
>> I would like to see addressed before publication.
>>
>
> Thanks for your comments and feedback, Les.  Please see below for some
> replies and questions.
>
> In Section 5.2 there is a definition of the information which is
>> required to be kept by an I2RS Agent for each I2RS interaction. I would
>> like to see the addition of "Request State" into this list.
>> Operationally each request could be in one of the following states:
>>
>>
>>
>> · Enqueued (or pending if you prefer)
>>
>> · In process
>>
>> · Completed
>>
>>
>>
>> The lack of such a state seems to imply that both the queue time and the
>> processing time are insignificant. While I think this may be the case
>> for many requests, it will not always be the case. In queue time may be
>> lengthy due to other load on the Agent. Also, some requests -
>> particularly destructive requests which involve cleanup of resources -
>> may take a significant amount of time to complete.
>>
>
> Good observation.  Traceability was aimed mainly at the termination of the
> request, but I like the idea of tracing the state machine.
>
>
>>
>>
>> Along with this an additional timestamp - Processing Initiated - would
>> be useful to indicate when processing of the request actually began.
>>
>
> I don't know we need a new timestamp.  Perhaps we just need to rename
> "Request Timestamp" and "Result Timestamp" to "Start Timestamp" and "End
> Timestamp" to denote the time within the current state.  What do you think?
>
> s/Some notable elements on the architecture/ Some notable elements of
>> the architecture
>>
>
> Fixed.  Thanks!
>
>
>>
>>
>> Figure 1
>>
>>
>>
>> Not clear to me why Application IDs start at 0 but Client IDs start at 1.
>>
>
> Ah.  The numbers there are not IDs.  They are the number of actual things
> in the boxes above.  For Applications, there may be 0 to N for a given
> client.  For Clients, you need at least 1.  Does that make sense?
>
>
>>
>>
>> Figure 1
>>
>>
>>
>> Is the text "Op Data V" between I2RS Agent box and Routing System box
>> intentional?
>>
>
> Yes.  The 'V' is meant to be an arrow head pointed down.  The request and
> data go from Client to Agent whereas the Response goes from Agent to Client.
>
> We are open to suggestions on how to make this clearer.
>
>
>>
>>
>> Section 5.2
>>
>>
>>
>> Secondary Identity
>>
>>
>>
>> This is defined to be "opaque" yet if not provided the agent is supposed
>> to insert "an UNAVAILABLE value". This seems to be a contradiction
>> unless we have a publicly defined value that clients are prohibited from
>> using. Absent that you would need a "Secondary Identity Valid" indicator.
>>
>
> Good observation.  I think it's fine to say that this field must be
> logged.  If there is no application, then the field will be logged as
> empty.  If there is an application, then whatever value is provided will be
> logged.
>
> Do you feel strongly that we need a field to indicate Application Present?
>
>
>>
>>
>> Section 7.4
>>
>>
>>
>> s/establish an vendor-agnostic/establish a vendor-agnostic
>>
>
> Fixed.  Thanks!
>
> Joe
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] AD review of draft-ietf-i2rs-traceability-07

[Alia Atlas]

First, I would like to thank the authors, Joe, Carlos, and Gonzalo, for
their work on this draft.
I have done my AD review and find it a well-written and clear document.  I
did find a couple minor things to clean up.  A new draft is welcome now.  I
have requested an IETF Last Call and placed this draft on the IESG telechat
for May 5.

The most critical factor in getting a draft to the RFC Editor quickly is
the responsiveness of the shepherd and authors in responding to reviews and
deciding which comments will improve the document.


Minor:
1) Sec 5..2:  Transaction ID includes this note, " [NOTE: The
requirements for transactions and long-running requests are being discussed
in the NETCONF working group, and this text will follow the requirements
set forth there.]"  I think it's time to finalize these requirements.

2) Sec 6:  "This is only an early proposal. These values are subject to
change."  Please update to an example of a potential implementation or the
like,,,

Thank you all,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [RTG-DIR] RtgDir review: draft-ietf-i2rs-traceability-06.txt

[Alia Atlas]

Mach,

Thank you very much for your quick review.

Regards,
Alia

On Mon, Jan 18, 2016 at 3:10 AM, Mach Chen  wrote:

> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-i2rs-traceability-06.txt
>  Reviewer: Mach Chen
>  Review Date: 2016/1/18
>  IETF LC End Date:
>  Intended Status: Standard Track
>
> Summary:
>  I have some minor concerns about this document that I think should be
> resolved before publication.
>
> Comments:
>  The document is well written and easy to read.
>
>
> Minor Issues:
>
> 1.
> The draft Intended status shows: Standards Track, but the Intended RFC
> status in the datatracker is "Informational". I think the latter is true,
> right? If so, please update it accordingly.
>
>
> 2.
> Section 5.2
> Client Address:   This is the network address of the Client that
>   connected to the Agent.  For example, this may be an IPv4 or IPv6
>   address.  [Note: will I2RS support interactions that have no
>   network address?  If so this field will need to be updated.]
>
> IMHO, the Note should be deleted for a to-be-published document. The IPv4
> and IPv6 are just examples, the description here does not exclude other
> possibilities.
>
>
> 3. Section 5.2
> Requested Operation Data:   This field comprises the data passed to
>   the Agent to complete the desired operation.  For example, if the
>   operation is a route add operation, the Operation Data would
>   include the route prefix, prefix length, and next hop information
>   to be inserted as well as the specific routing table to which the
>   route will be added.  The operation data can also include
>   interface information.
>
> Although the last sentence above is right, why do we need to emphasize the
> "interface information" here? If there is no special intention, I'd suggest
> to remove it.
>
>
> 3. Section 5.2
> Transaction ID:   The Transaction Identity is an opaque string that
>   represents this particular operation is part of a long-running
>   I2RS transaction that can consist of multiple...
>
> Here you specify that an Transaction ID is an opaque string, are there
> other possibilities (e.g., uint) ? Since this is just an information model,
> how the data type should be is specific to the data model, I'd suggest to
> remove the data type limitation from this document.
>
>
> Best regards,
> Mach
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I-D Action: draft-ietf-i2rs-problem-statement-07.txt

[Alia Atlas]

I have updated this draft in response to Deborah's AD review and Nabil's
rtg-dir review.

I would greatly appreciate it if others could read/reread this draft and
send additional comments
and suggestions.

As you probably know, we're discouraging publishing drafts that
don't
really need to live as RFCs and a category to examine carefully is
certainly problem-statements. 

As an author, I feel that this draft has some useful and unique material
primarily in Section 5.  I also think that Section 4 outlines some of the
assumptions and needs for a feedback loop with push notifications, that the
architecture draft simply assumes.  I do think that this draft provides
useful context for I2RS - but I am also very open to hearing others
opinions on whether having this
information as an RFC is likely to be useful.

Thanks,
Alia

On Thu, Dec 17, 2015 at 11:42 AM, <internet-dra...@ietf.org> wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>  This draft is a work item of the Interface to the Routing System Working
> Group of the IETF.
>
> Title   : Interface to the Routing System Problem Statement
>     Authors : Alia Atlas
>   Thomas D. Nadeau
>   Dave Ward
> Filename: draft-ietf-i2rs-problem-statement-07.txt
> Pages   : 11
> Date: 2015-12-17
>
> Abstract:
>Traditionally, routing systems have implemented routing and signaling
>(e.g.  MPLS) to control traffic forwarding in a network.  Route
>computation has been controlled by relatively static policies that
>define link cost, route cost, or import and export routing policies.
>With the advent of highly dynamic data center networking, on-demand
>WAN services, dynamic policy-driven traffic steering and service
>chaining, the need for real-time security threat responsiveness via
>traffic control, and a paradigm of separating policy-based decision-
>making from the router itself, the need has emerged to more
>dynamicaly manage and program routing systems in order to control
>routing information and traffic paths and to extract network topology
>information, traffic statistics, and other network analytics from
>routing systems.
>
>This document proposes meeting this need via an Interface to the
>Routing System (I2RS).
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-i2rs-problem-statement-07
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-problem-statement-07
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement

[Alia Atlas]

Hi Nabil,

Thank you very much for doing this very useful review.  I have posted
draft-ietf-i2rs-problem-statement-07 and the differences can be seen at:
https://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-problem-statement-06=draft-ietf-i2rs-problem-statement-07=--hwdiff

I did take a number of your wording changes in.  If you can take a look at
the updated
draft, that would be useful.

Thanks,
Alia

On Mon, Jun 15, 2015 at 7:51 PM, Susan Hares <sha...@ndzh.com> wrote:

> Nabil:
>
>
>
> Thank you for this review.  The I2RS chairs appreciate the careful
> review.  I think we are aligned with you that we want a fresh-updated
> draft-ietf-i2rs-problem-statement.  Alia Atlas (one of the co-author) and I
> will chat within a day or so and get back to you on the nits.
>
>
>
> Sue
>
>
>
> *From:* Bitar, Nabil N [mailto:nabil.n.bi...@verizon.com]
> *Sent:* Monday, June 15, 2015 7:38 PM
> *To:* draft-ietf-i2rs-problem-statem...@tools.ietf.org; rtg-...@ietf.org
> *Cc:* rtg-...@tools.ietf.org; BRUNGARD, DEBORAH A; Jonathan Hardwick;
> i2rs-cha...@ietf.org
> *Subject:* [RTG-DIR] Routing directorate review of
> draft-ietf-i2rs-problem-statement
>
>
>
>  Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft.
> The Routing Directorate seeks to review all routing or routing-related
> drafts as they pass through IETF last call and IESG review, and sometimes
> on special request. The purpose of the review is to provide assistance to
> the Routing ADs. For more information about the Routing Directorate, please
> see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through
> discussion or by updating the draft.
>
> Document: draft-ietf-i2rs-problem-statement-06.txt
>
> Reviewer: Nabil Bitar
> Review Date: 6/14/2015
> IETF LC End Date: Unknown
> Intended Status: Informational
>
> *Summary:*
>
> I have some minor concerns about this document that I think should be
> resolved before publication. The document has nits that should also be
> considered prior to publication.
>
> *Comments:*
>
> This document is intended to describe the problem that i2rs needs to
> address. The document readability can be improved by::
>
>1. starting with the abstract, clearly and progressively stating what
>i2rs is, the driver for the problem to be addressed, and the
>objective/problem to be solved. Comments that address this issue are
>aprovided.
>
> I took several of thse comments in.

>
>1.
>2. Clearly identifying early in the document where currently solutions
>that seem to be addressing the problem fail. This is a key component of the
>problem statement. This is currently left ambiguous to the reader untiil
>the appendix. For instance, the document may refer to the appendix early
>on, pointing the reader to gaps in existing interfaces for managing routing
>information compared to the needs.
>
> Please check if this is adequately addressed.  There's a fine line between
talking about new functionality that is useful and bashing existing and
highly successful solutions.

>
>1.
>2. Defining or referring to the definition of terminology used in the
>document
>
> I added "*This document uses terminology defined in  *
*[I-D.ietf-i2rs-architecture]* in Section 2.

>
>1.
>
> *Major Issues:*
>
> No major issues found
>
> *Minor Issues:*
>
> 1- Abstract: I suggest the addition of the following at the beginning of
> the first paragraph:
>
> Traditionally, routing systems have implemented routing and signaling
> (e.g., multiprotcol label switch) protocols to control traffic forwarding
> in a network. Route computation has been controlled by relatively static
> policies that define link cost, route cost or import and export routing
> policies. With the advent of highly dynamic data center networking,
> on-demand WAN services, dynamic policy-driven traffic steering and service
> chaining, the need for real-time security threat responsiveness via traffic
> control,  and the software defined networking paradigm, the need has
> emerged to  more dynamically manage and program routing systems in order to
> control routing information and  traffic paths, and to extract network
> topology information and traffic statistics, among others, from routing
> systems. As modern networks continue to grow …… (the rest of the first
> paragraph in the abstract.
>
> 2-Abstract: second paragraph first sentence, suggest the following
> modifica

Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03

[Alia Atlas]

>From my perspective, adding encap for a next-hop in the RIB makes sense.
>From one perspective,
this is just putting, for instance, an MPLS label on.  However, the RIB
supports using additional
higher-level abstractions.  So - the RIB might use an interface that is to
a tunnel - but the RIB may
also have a next-hop that indicates adding the encap associated with an LSP
or a tunnel.  This
allows the RIB's next-hop to stay the same when the LSP or tunnel changes.

I don't see the same rationale for decap.  I'm most familiar with MPLS -
where the label has an
operation that is popping or swapping.  For VXLAN or GRE, the outer dest IP
address would
indicate the router and thus be decapsulated.

I see the role of the RIB as specifying what packets should go out what
interface with appropriate
encaps.  It's not creating the tunnel but merely putting packet(s) into the
tunnel (or LSP or MPLS label stack)
 at the desired level of abstraction.  The discussion about decapsulation
feels much more to me like it is creating the tunnel.

Obviously, I'm happy to listen to other perspectives.

Regards,
Alia


On Wed, Nov 18, 2015 at 3:36 AM, Mach Chen  wrote:

> Indeed, I agree with Jeffery here.
>
> I'd suggest we keep the current model as is and address the vxlan/nvgre
> decap in other places.
>
> Best regards,
> Mach
>
> > -Original Message-
> > From: Jeffrey (Zhaohui) Zhang [mailto:zzh...@juniper.net]
> > Sent: Tuesday, November 17, 2015 6:00 AM
> > To: Nitin Bahadur; Manish Kumar (manishkr); Chris Bowers; Mach Chen;
> > i2rs@ietf.org
> > Subject: RE: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03
> >
> > Current RIB has ieee-mac RIB, which could use vxlan encap nexthops.
> >
> > BTW, mpls encap/decap is needed even for non-segmenting scenarios - plain
> > old l3vpn, vpls, or evpn with mpls data plane.
> >
> > Jeffrey
> >
> > > -Original Message-
> > > From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Nitin Bahadur
> > > Sent: Monday, November 16, 2015 4:16 PM
> > > To: Manish Kumar (manishkr) ; Chris Bowers
> > > ; Mach Chen ;
> > i2rs@ietf.org
> > > Subject: Re: [i2rs] feedback on draft-ietf-i2rs-rib-data-model-03
> > >
> > >
> > > We need a minimal tunnel encap for MPLS.so that mpls labels can be
> > > pushed and popped. So I do want to keep basic (aka mpls) tunnel
> > > encap/decap in this draft. This will also enable development of
> > > solutions based on Segment routing (or whatever it's called these
> days).
> > >
> > > Nitin
> > >
> > > On 11/16/15, 12:17 PM, "Manish Kumar (manishkr)" 
> > > wrote:
> > >
> > > >Encap/Decap belong to a different layer (actually one that ties two
> > > layers
> > > >together) and RIB doesn't look the right place for encap/decap to me.
> > > >
> > > >Thanks,
> > > >Manish
> > > >
> > > >On 17/11/15 1:25 am, "i2rs on behalf of Nitin Bahadur"
> > > > wrote:
> > > >
> > > >>
> > > >>
> > > >>>I find it odd that the current data model provides the ability to
> > > >>>configure encap, but not decap, for VXLAN.  This would require the
> > > >>>user of the data model to configure VXLAN tunnel-encap  using one
> data
> > model
> > > >>>and vxlan-decap using another data model.   I think this is perhaps
> an
> > > >>>indication that VXLAN encap does not belong in the RIB data model
> > > >>>either.
> > > >>
> > > >>I¹ll buy that argument. And I believe we can extend that argument to
> > > >>GRE & NVGRE as well.
> > > >>
> > > >>Anyone on the list have comments related to this?
> > > >>
> > > >>Thanks
> > > >>Nitin
> > > >>
> > > >>
> > > >>___
> > > >>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

Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt

[Alia Atlas]

Acee,

As Sue has said, the I2RS Info Model has passed WGLC and is just waiting
for the DM to be done in order to progress.  Obviously, substantial
technical concerns are always welcome - there's a long way between WGLC and
final IESG approval; I do not think that you have clearly described your
technical concerns.  Are you mixing up using a tunnel for forwarding with
provisioning the tunnel??

The I2RS RIB model is not for provisioning tunnels.  It is intended so that
traffic can be forwarded properly, regardless of the abstraction.  For
instance, with MPLS, a packet could be sent out with an arbitrary label or
label stack, a packet could follow an LSP, or a packet could follow a
tunnel.   By providing the ability to forward via these different layers of
abstraction, the RIB model allows forwarding to occur correctly even when a
tunnel or LSP changes - just like a next-hop can be specified to forward
like a different prefix and then follows that prefix.

I certainly do not see the I2RS RIB model as creating tunnels - but merely
being able to use ones that already exist.

Now, if your objection is that the I2RS RIB model should use a common
grouping that describes all types of tunnels, I have yet to see one.  The
efforts to provide YANG models for tunnels are still quite immature.
Describing what types of groupings would be useful is the type of work that
I hope the design team will do.
Asking I2RS to stall until time can be dedicated isn't appropriate.

Regards,
Alia



On Tue, Nov 24, 2015 at 8:34 AM, Acee Lindem (acee) <a...@cisco.com> wrote:

> From: Susan Hares <sha...@ndzh.com>
> Date: Monday, November 23, 2015 at 9:57 PM
> To: Acee Lindem <a...@cisco.com>, "i2rs@ietf.org" <i2rs@ietf.org>
> Cc: Alia Atlas <akat...@gmail.com>, Jeff Haas <jh...@pfrc.org>, Jeff
> Tantsura <jeff.tants...@ericsson.com>
> Subject: RE: [i2rs] FW: I-D Action: draft-ietf-i2rs-rib-data-model-04.txt
>
> Acee:
>
>
>
> Is your input individual input or input from the routing architecture for
> yang models?
>
>
> Individual.
>
>
>
>
> 
>
> The routing architecture for yang models is incomplete without the
> consideration of the I2RS ephemeral state and I2RS architecture.  Asking
> the I2RS WG to change a document that is in WG LC based on an incomplete
> architectural document is not reasonable.
>
>
> My comment with respect to tunnel provisioning is not based on any
> architecture document.
>
> An alignment between
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/ without
> the consideration of the I2RS ephemeral state is an incomplete alignment
> and a problematic  approach for I2RS WG’s efforts.
>
>
> I2RS models should augment the base models with ephemeral state.
>
>
>
>
> In a volunteer organization, each person has the right to makes choices in
> what they have time to do.   If you do not have bandwidth to provide an
> adequate routing architecture for yang models that considers ephemeral
> state or its needs, that is your choice.  Unless you have a concrete
> proposal for the ephemeral state that covers I2RS RIB and
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/, the I2RS
> WG LC will be closed after 2 week (11/23 – 12/7) WG review of the in 
> draft-ietf-i2rs-rib-data-model-04.txt.
>
>
>
> We have proposed tunnel models, draft-ietf-netmod-routing-cfg is not meant
> to supplant them. BTW, we don’t plan to
> update draft-ietf-i2rs-rib-data-model-04.txt. Updates based on I2RS will be
> in the a next-hop augmentation draft that extends
> draft-ietf-netmod-rtg-cfg.
>
>
>
>
>
> Please remember that the I2RS RIB model has two parts:  I2RS Informational
> Model and I2RS Data Model.  The I2RS Informational Model and the I2RS
> Data Model have descriptions on the soft tunnel provisioning as
> mechanisms.  Questions at this point must demonstrate a knowledge of these
> documents or suggest specific changes to the documents.   If you wish to
> raise the following questions, please do this in light of specific sections
> that include both the I2RS Informational Model, the I2RS Data Model, and
> I2RS architecture.
>
>
>
> a)  I2RS tunnels must include additions beyond encapsulation,
>
> b)  Why the I2RS Informational Model and the I2RS Data Model do not
> provide the soft tunnel provisioning or describe the specifics of this
> provision?
>
>
>
> The I2RS Informational Model has examples for these tunnels.  You are
> welcome to make proposal for specific changes to the I2RS Informational
> Model or the I2RS Data Model.  The I2RS Informational Model has completed
> WG LC so the bar for substantive comments is high.
>
>
> I don’t believe this excerpt from the RIB information m

Re: [i2rs] Conversation on Priority and Panes

[Alia Atlas]

Hi Russ & Andy,

I certainly understand the desire for different behavior when a priority
override happens.
However, this is one area where the working group was extremely clear.  Sue
and I had
ideas of store-if-not-best and handling overwrites and so on.  There was a
very clear
push back against any such complexity.  Feel free to take a read through
the archive.

While it is tempting to expand the scope and functionality of I2RS to
handle this as not
an error, I would ask that we respect the WG consensus and get agreement
and implementations
going on the basics.

We have a serious case of too many saying "This is an interesting soup.
Let's watch it." and
far too few people putting wood on the fire and experimenting.

Regards,
Alia

On Thu, Nov 5, 2015 at 12:57 PM, Andy Bierman  wrote:

>
>
> On Thu, Nov 5, 2015 at 12:10 AM, Russ White <7ri...@gmail.com> wrote:
>
>>
>> > First, is the case of two I2RS clients modifying the same "thing"
>> > something we consider normal and desirable, or is it an error.  The
>> earlier
>> > discussions was that it is an error.  In discussing the many different
>> kinds of
>> > direct and indirect collateral issues that arise, we concluded that we
>> could
>> > not expect the I2RS agent to be able to determine the "right" thing to
>> do
>> in
>> > the general case.
>>
>> So, assume the following --
>>
>> 1. A local BGP process installs a route, 10.1.1.0/24 via 192.168.100.1
>> 2. In order to move traffic off a "hot link" in a fabric, a
>> client/controller installs a route, 10.1.1.0/24 via 192.168.200.1
>> 3. An attack vector is detected in a flow destined to some host on
>> 10.1.1.0/24 that causes a separate client/controller to install a route,
>> 10.1.1.0/24 via 192.168.150.1 for five seconds
>>
>> If I were the operator who owned this network, I wouldn't call this an
>> "error." I would call this "normal operation," -- in fact, the ability to
>> do
>> the above would be the very reason I would deploy I2RS on the network in
>> the
>> first place. Further, I would expect the entire process to unwind properly
>> and _quickly_. I don't care how it happens, I just want the removal of the
>> second client's route to leave the first client's in the table as the
>> current route, and the removal of the first client's path leave the BGP
>> route as the best path. To go farther, why are there client priorities at
>> all if this is an "error?" If all overwrites of "ephemeral state" are an
>> error, the agent should simply reject any attempt to overwrite any such
>> state.
>>
>>
>
> I agree that a priority override is not an error. In a multi-client
> environment,
> client A is not going to know about the other clients added to the system.
> This is true whether the clients are primary or secondary behind a broker.
>
> The notification to a client that some or all of its data was just
> overridden
> is a separate matter from whether the client wants all or part of its
> data to be removed or altered.
>
> One proposal to the design team is the notion that the server
> supports an advertised (static) number of clients (max client panes).
> Each client must be assigned a priority, such that every client
> has its own pane, so adding a valid edit does not fail. Activating
> the edit is a separate matter. Each client can flush all or part of its
> own pane.
>
>
> :-)
>>
>> Russ
>>
>>
>
> Andy
>
>
> ___
> 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

Re: [i2rs] draft-mglt-i2rs-security-environment-reqs, REQ 3

[Alia Atlas]

no-hats

Good catch - this seems to be very aspirational and contradicts
what the architecture says - which is basically that the user may
cause issues.

Regards,
Alia
/no-hats

On Thu, Aug 27, 2015 at 4:32 PM, Jeffrey Haas jh...@pfrc.org wrote:

 I've been reviewing the environment requirements, thanks for picking up
 this
 work.  Requirement 3 contains the following:

REQ 3:  The I2RS Agent validates data to ensure injecting the
information will not create a deadlock with any other system,
nor will it create a routing loop, nor will it cause the
control plane to fail to converge.

 I2RS has already received feedback from our netconf experts expressing
 concern over how validation even at the schema levels may introduce
 excessive latency.  This contradicts the I2RS need for speed.

 I have a broader concern that the above requirement may simply be an
 intractable problem.  It's a loft goal, but the overhead in validating all
 such things is likely not within the goal of speed.

 Thoughts?

 -- Jeff

 ___
 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

Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00

[Alia Atlas]

Hi Diego,

The secondary identity is just an opaque value to allow traceability.  It's
to support a
client easily being a broker for multiple applications.  I don't agree that
there is value
in trying to secure the secondary identity the way you are describing.
This path leads
to there being basically no value for having secondary identities.

Regards,
Alia

On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA 
diego.r.lo...@telefonica.com wrote:


 --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 charset=us-ascii

 Hi Alia,

 Just a remark on your comment about section 3.1: I think the current =
 requirement of associating a single secondary identity per connection =
 does make sense if we want to keep traceability over I2RS secure =
 transports.=20

 You need to associate secondary identities with primary ones in a secure =
 way to guarantee such traceability, and the mechanisms for this I can =
 imagine using current transports (such as a certificate extension or =
 alternate identity, or additional information in secure tokens) are =
 associated with connection handshake, and therefore re-association is =
 complicated to implement without restarting the connection. Note I say =
 complicated, not impossible, but I cannot see the advantage in the =
 additional complexity, especially when experience shows that additional =
 complexity becoming source of security flaws...

 Be goode,

 On 11 Jun 2015, at 22:11 , Alia Atlas akat...@gmail.com wrote:

  no-hat
 =20
  Sue,
 =20
  Thanks for writing this draft.  I think it is useful to clearly =
 articulate the outside-of-I2RS behavior and protocols that are needed =
 for the mutual authentication.  I do have a couple comments on the =
 draft.
 =20
 =20
  In Sec 3.1, it says Each Identity will be linked to one secondary =
 identity for the period of a connection.  I would have assumed that the =
 client could arbitrarily change its' secondary identity.  This is to =
 support the broker case where a client may be passing along requests =
 from multiple applications.  Since the secondary identity is just passed =
 along and stored for traceability, I don't think that allowing it to =
 change would cause significant complications.   What do others think?
 =20
 =20
  In the I2RS architecture, there are 3 different types of transaction =
 behavior desired for processing a message. In Sec 4, there's an =
 assumption that fail-on-error with the associated roll-back is the =
 only mode.   Thus, I think that Section 4 needs a bit of massaging.
 =20
 =20
  Thanks,
 =20
  Alia
  ___
  i2rs mailing list
  i2rs@ietf.org
  https://www.ietf.org/mailman/listinfo/i2rs

 --
 Esta vez no fallaremos, Doctor Infierno

 Dr Diego R. Lopez
 Telefonica I+D
 http://people.tid.es/diego.lopez/

 e-mail: diego.r.lo...@telefonica.com
 Tel:+34 913 129 041
 Mobile: +34 682 051 091
 --


 --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html;
 charset=us-ascii

 htmlheadmeta http-equiv=3DContent-Type content=3Dtext/html =
 charset=3Dus-ascii/headbody style=3Dword-wrap: break-word; =
 -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;Hi =
 Alia,divbr/divdivJust a remark on your comment about section =
 3.1: I think the current requirement of associating a single secondary =
 identity per connection does make sense if we want to keep traceability =
 over I2RS secure transports.nbsp;/divdivbr/divdivYou need to =
 associate secondary identities with primary ones in a secure way to =
 guarantee such traceability, and the mechanisms for this I can imagine =
 using current transports (such as a certificate extension or alternate =
 identity, or additional information in secure tokens) are associated =
 with connection handshake, and therefore re-association is complicated =
 to implement without restarting the connection. Note I say complicated, =
 not impossible, but I cannot see the advantage in the additional =
 complexity, especially when experience shows that additional complexity =
 becoming source of security flaws.../divdivbr/divdivBe =
 goode,/divdivbrdivdivOn 11 Jun 2015, at 22:11 , Alia Atlas =
 lt;a href=3Dmailto:akat...@gmail.com;akat...@gmail.com/agt; =
 wrote:/divbr class=3DApple-interchange-newlineblockquote =
 type=3Dcitemeta http-equiv=3DContent-Type content=3Dtext/html; =
 charset=3Dutf-8div dir=3Dltrlt;no-hatgt;brbrSue,brbrThanks=
  for writing this draft.nbsp; I think it is useful to clearly =
 articulate the outside-of-I2RS behavior and protocols that are needed =
 for the mutual authentication.nbsp; I do have a couple comments on the =
 draft.brbrbrIn Sec 3.1, it says Each Identity will be linked to =
 one secondary identity for the period of a connection. nbsp;I would =
 have assumed that the client could arbitrarily change its

Re: [i2rs] quick comment on draft-hares-i2rs-auth-trans-00

[Alia Atlas]

Hi Diego,
On Jun 23, 2015 9:41 AM, DIEGO LOPEZ GARCIA diego.r.lo...@telefonica.com
wrote:

  Hi Alia,

  My understanding was that secondary identity was not intended to be only
 a general declaration made by the client, in which case what you say
 definitely holds. If the trust model at the agent does not completely rely
 on client assertions, the only way in which I see you can ensure
 traceability is by associating data with a minimum level of assurance, in
 despite of those data being opaque or not to the entities providing or
 recording them.


I believe that the secondary identity is intended to be only a general
declaration made by the client.  It's the minimum to provide some
traceability without complicated support for the broker client model.  That
is why it is merely an opaque value to the agent; it has no meaning and
isn't verified but merely stored.

With the primary identity verified and an integrity-protected channel for
writing state, I think that secondary identity will be whatever the
associated client sent.  By having that opaque value recorded, an operator
can compare it to what the client thinks was happening.

Certainly, that's the discussion and conclusion that I recall and I haven't
seen any further discussion to make me think that the conclusion has
changed.

Regards,
Alia



  If the first assumption holds, I'll stay corrected and support your
 comment to section 3.1. If not, I'd say I have a point here...

  Be goode,

   On 23 Jun 2015, at 14:10 , Alia Atlas akat...@gmail.com wrote:

  Hi Diego,

  The secondary identity is just an opaque value to allow traceability.
 It's to support a
 client easily being a broker for multiple applications.  I don't agree
 that there is value
 in trying to secure the secondary identity the way you are describing.
 This path leads
 to there being basically no value for having secondary identities.

  Regards,
 Alia

 On Tue, Jun 23, 2015 at 9:02 AM, DIEGO LOPEZ GARCIA 
 diego.r.lo...@telefonica.com wrote:


 --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/plain;
 charset=us-ascii

 Hi Alia,

 Just a remark on your comment about section 3.1: I think the current =
 requirement of associating a single secondary identity per connection =
 does make sense if we want to keep traceability over I2RS secure =
 transports.=20

 You need to associate secondary identities with primary ones in a secure =
 way to guarantee such traceability, and the mechanisms for this I can =
 imagine using current transports (such as a certificate extension or =
 alternate identity, or additional information in secure tokens) are =
 associated with connection handshake, and therefore re-association is =
 complicated to implement without restarting the connection. Note I say =
 complicated, not impossible, but I cannot see the advantage in the =
 additional complexity, especially when experience shows that additional =
 complexity becoming source of security flaws...

 Be goode,

 On 11 Jun 2015, at 22:11 , Alia Atlas akat...@gmail.com wrote:

  no-hat
 =20
  Sue,
 =20
  Thanks for writing this draft.  I think it is useful to clearly =
 articulate the outside-of-I2RS behavior and protocols that are needed =
 for the mutual authentication.  I do have a couple comments on the =
 draft.
 =20
 =20
  In Sec 3.1, it says Each Identity will be linked to one secondary =
 identity for the period of a connection.  I would have assumed that the =
 client could arbitrarily change its' secondary identity.  This is to =
 support the broker case where a client may be passing along requests =
 from multiple applications.  Since the secondary identity is just passed =
 along and stored for traceability, I don't think that allowing it to =
 change would cause significant complications.   What do others think?
 =20
 =20
  In the I2RS architecture, there are 3 different types of transaction =
 behavior desired for processing a message. In Sec 4, there's an =
 assumption that fail-on-error with the associated roll-back is the =
 only mode.   Thus, I think that Section 4 needs a bit of massaging.
 =20
 =20
  Thanks,
 =20
  Alia
  ___
  i2rs mailing list
  i2rs@ietf.org
  https://www.ietf.org/mailman/listinfo/i2rs

 --
 Esta vez no fallaremos, Doctor Infierno

 Dr Diego R. Lopez
 Telefonica I+D
 http://people.tid.es/diego.lopez/

 e-mail: diego.r.lo...@telefonica.com
 Tel:+34 913 129 041
 Mobile: +34 682 051 091
 --


 --Apple-Mail=_B6401857-FE32-45EF-A393-65E1C90F6FC1
 Content-Transfer-Encoding: quoted-printable
 Content-Type: text/html;
 charset=us-ascii

 htmlheadmeta http-equiv=3DContent-Type content=3Dtext/html =
 charset=3Dus-ascii/headbody style=3Dword-wrap: break-word; =
 -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;Hi =
 Alia,divbr/divdivJust a remark on your comment about section =
 3.1: I think the current

[i2rs] quick comment on draft-hares-i2rs-auth-trans-00

[Alia Atlas]

no-hat

Sue,

Thanks for writing this draft.  I think it is useful to clearly articulate
the outside-of-I2RS behavior and protocols that are needed for the mutual
authentication.  I do have a couple comments on the draft.


In Sec 3.1, it says Each Identity will be linked to one secondary identity
for the period of a connection.  I would have assumed that the client
could arbitrarily change its' secondary identity.  This is to support the
broker case where a client may be passing along requests from multiple
applications.  Since the secondary identity is just passed along and stored
for traceability, I don't think that allowing it to change would cause
significant complications.   What do others think?


In the I2RS architecture, there are 3 different types of transaction
behavior desired for processing a message. In Sec 4, there's an assumption
that fail-on-error with the associated roll-back is the only mode.
Thus, I think that Section 4 needs a bit of massaging.


Thanks,

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

[i2rs] storage of priority and client ID with a node

[Alia Atlas]

no-hat
As I mentioned in the virtual interim, I'd like to explain a little further
about what I see as semantics and desired behavior around the storing and
managing of priority and client ID.

First, the priority mechanism is intended to handle error cases of
colliding writes in a predictable way that results in a consistent
mechanism.  It is true that the same mechanism could be used if they
weren't considered errors.  I think this is a nice property - but it is
also important to minimize the impact of the priority mechanism.

Second, if there is a priority conflict where both clients (Client_A and
Client_B) share the same priority, the client that wrote first wins.  This
is to avoid network oscillation if two clients are fighting over writing
the same state.  When there are multiple clients and the time arrival of
the messages may not be predictable (network transit differences, which
socket is read, software differences), basing state on last arrival time
doesn't give consistent and predictable behavior.

That gives behavior as in the following time-line:
Time_1:  Client_A writes X=N with priority 10
Time_2:  Client_B attempts to write X=K with priority 10 and is rejected
Time_3:  Client_A writes X=P with priority 10 and succeeds

For the I2RS Agent to properly handle these actions, it is necessary to
know that X is owned by Client_A.  Priority alone is not sufficient because
the basis for rejecting Client_B's write but accepting Client_A's write is
that Client_A is the owner.

Thus, I believe that it is necessary to store the Client Identity with the
nodes that it owns.
This could be in an I2RS-specific overlay that is only used by the I2RS
agent and only contains the nodes that have been written by I2RS.

Third, a question has come up regarding what the behavior of priority is if
a client's priority changes and whether priority needs to be stored with
each node when that node is written.

In my keep-it-simple perspective, priority is associated with a Client
and is only used on a conflict.  This would mean that priority isn't stored
with a node when that node is written.  Instead, the Client Identity is
stored with the node and the Client's priority is looked up in a client
table that the I2RS Agent can access.  That client table could be populated
via configuration, via a AAA protocol, via NACM, etc.

The semantic implications are as follows:
  Time_1:  Client_A writes X=N with priority 10
  Time_2:  Client_A's priority is changed (UNUSUAL) to priority 6
 *Time_3:  Client_B writes X=K with priority 8  (succeeds since 8  6)
 *Time_4:  Client_A attempts to write X=N with priority 6  (fails b/c 8
 6)
  Time_5:  Client_B's priority is changed (UNUSUAL) to priority 7
  Time_6   Client_B writes X=P with priority 7 and succeeds (same
owner, no priority check)

The alternate approach would have store the priority with which a node was
written.  That is more like a priority lock that could only be changed by a
client with higher priority or by the same client, regardless of priority.
This approach would require storing a priority per node and the semantic
implications would be as follows:

  Time_1:  Client_A writes X=N with priority 10
  Time_2:  Client_A's priority is changed (UNUSUAL) to priority 6
 *Time_3:  Client_B attempts to write X=K with priority 8  and fails
(10  8)
 *Time_4:  Client_A writes X=N with priority 6  succeeds (same owner,
no priority check)
  Time_5:  Client_B's priority is changed (UNUSUAL) to priority 7
  Time_6   Client_B writes X=P with priority 7 and succeeds (7  6)

The behavior for these two models is different at Time_3 and Time_4.

I'd like to see if there's agreement that the first model (priority stored
with client) is acceptable or if the second model (priority stored with
node) is necessary.

Thanks,
Alia
/no-hat
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Alia Atlas]

On Wed, Jun 3, 2015 at 1:15 PM, Andy Bierman a...@yumaworks.com wrote:

 On Wed, Jun 3, 2015 at 10:02 AM, Alia Atlas akat...@gmail.com wrote:
  Andy,
 
  On Fri, May 29, 2015 at 8:41 PM, Andy Bierman a...@yumaworks.com
 wrote:
 
  On Fri, May 29, 2015 at 2:55 PM, Susan Hares sha...@ndzh.com wrote:
   Andy:
  
  
  
   On all actions working or not – you should look at section 7.9 of the
   architecture.  It allows “perform all or none”, “perform until error”,
   and
   “perform all storing errors.”I will propose an addition to section
   2.4
   to Jeff’s document:
  
  
 
  OK -- I remember these options now.
 
  It should be clear in the document that stopping on error or recording
  errors does not mean the agent will leave the datastore in an invalid
  state.  Most YANG validation errors can be pruned from the datastore.
  This may or may not leave the datastore in an operationally useful
 state.
  The must/min-elements/unique statements can cause validation errors
  on nodes outside the edit list.
 
  NETCONF does not allow validation errors in the running datastore.
  I2RS should not allow validation errors in the ephemeral data.
 
 
  I agree.  For the stop-on-error, when one operation in the message
 causes an
  error,
  that operation is not done (can't b/c of error) AND no operations after
 that
  in the
  message are done.  For recording errors, all operations in the message
 are
  attempted in order and any errors are recorded to send back to the
 client.
  If an operation caused an error, then the operation isn't completed.
 
  Does that make sense?
 


 I think so. This is a sharp knife. Developers using anything
 except 'all-or-none' will need to be very knowledgeable about the
 data models in use in order for partial edits to be practical.
 But I think the draft makes this clear.


I should have read further in the thread before responding. I saw that you
gave exactly this with good clear examples.

Alia




  Regards,
  Alia
 
 

 Andy

 
 
  Andy
 
  
   2.4 ) Transaction to ephemeral state:
  
  
  
   The ephemeral state should support a multiple parts of a operation
   occurring
   in a single message, but it does not require multi-message atomicity
 and
   rollback. Three types of error handling should be supported:
  
  
  
  Perform all or none:   This traditional SNMP semantic indicates
 that
  
 other I2RS agent will keep enough state when handling a single
  
 message to roll back the operations within that message.  Either
  
 all the operations will succeed, or none of them will be applied
  
 and an error message will report the single failure which caused
  
 them not to be applied.  This is useful when there are, for
  
 example, mutual dependencies across operations in the message.
  
  
  
  Perform until error:   In this case, the operations in the message
  
 are applied in the specified order.  When an error occurs, no
  
 further operations are applied, and an error is returned
  
 indicating the failure.  This is useful if there are
 dependencies
  
 among the operations and they can be topologically sorted.
  
  
  
  Perform all storing errors:   In this case, the I2RS Agent will
  
 attempt to perform all the operations in the message, and will
  
 return error indications for each one that fails.  This is
 useful
  
 when there is no dependency across the operation, or where the
  
 client would prefer to sort out the effect of errors on its own.
  
  
  
  In the interest of robustness and clarity of protocol state, the
  
  protocol will include an explicit reply to modification or write
  
  operations even when they fully succeed.
  
  
  
  
  
   Will this cover the architecture document 7.9 transactions impact on
   ephemeral state?
  
  
  
   Sue Hares
  
  
  
   From: Susan Hares [mailto:sha...@ndzh.com]
   Sent: Friday, May 29, 2015 1:44 PM
   To: 'Andy Bierman'
   Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';
   'i2rs@ietf.org'; 'chen@zte.com.cn'; 'Alia Atlas'
   Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00
  
  
  
   Andy:
  
  
  
   I missed the second part of the email
   (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in
 my
   earlier message:
  
  
  
  .  The last paragraph sounds like some nodes will be accepted and
   others
   rejected.
  
  If any nodes are rejected, the entire edit should be rejected.
  
  
  
   RESTCONF does an atomic action within a http session.   NETCONF
 within a
   commit.  Section 6.2 of the I2RS architecture document describes state
   storage for I2RS, and it does not have the atomic requirement for the
   protocol.  Instead section 3.3 of the I2RS architecture document calls
   for
   this to be model driver.  Let me provide examples from the 2 major
 I2RS
   protocol independent models:
  
  
  
   The I2RS RIB yang

Re: [i2rs] draft-chen-i2rs-identifier-management-00

[Alia Atlas]

Andy,

On Fri, May 29, 2015 at 8:41 PM, Andy Bierman a...@yumaworks.com wrote:

 On Fri, May 29, 2015 at 2:55 PM, Susan Hares sha...@ndzh.com wrote:
  Andy:
 
 
 
  On all actions working or not – you should look at section 7.9 of the
  architecture.  It allows “perform all or none”, “perform until error”,
 and
  “perform all storing errors.”I will propose an addition to section
 2.4
  to Jeff’s document:
 
 

 OK -- I remember these options now.

 It should be clear in the document that stopping on error or recording
 errors does not mean the agent will leave the datastore in an invalid
 state.  Most YANG validation errors can be pruned from the datastore.
 This may or may not leave the datastore in an operationally useful state.
 The must/min-elements/unique statements can cause validation errors
 on nodes outside the edit list.

 NETCONF does not allow validation errors in the running datastore.
 I2RS should not allow validation errors in the ephemeral data.


I agree.  For the stop-on-error, when one operation in the message causes
an error,
that operation is not done (can't b/c of error) AND no operations after
that  in the
message are done.  For recording errors, all operations in the message are
attempted in order and any errors are recorded to send back to the client.
If an operation caused an error, then the operation isn't completed.

Does that make sense?

Regards,
Alia




 Andy

 
  2.4 ) Transaction to ephemeral state:
 
 
 
  The ephemeral state should support a multiple parts of a operation
 occurring
  in a single message, but it does not require multi-message atomicity and
  rollback. Three types of error handling should be supported:
 
 
 
 Perform all or none:   This traditional SNMP semantic indicates that
 
other I2RS agent will keep enough state when handling a single
 
message to roll back the operations within that message.  Either
 
all the operations will succeed, or none of them will be applied
 
and an error message will report the single failure which caused
 
them not to be applied.  This is useful when there are, for
 
example, mutual dependencies across operations in the message.
 
 
 
 Perform until error:   In this case, the operations in the message
 
are applied in the specified order.  When an error occurs, no
 
further operations are applied, and an error is returned
 
indicating the failure.  This is useful if there are dependencies
 
among the operations and they can be topologically sorted.
 
 
 
 Perform all storing errors:   In this case, the I2RS Agent will
 
attempt to perform all the operations in the message, and will
 
return error indications for each one that fails.  This is useful
 
when there is no dependency across the operation, or where the
 
client would prefer to sort out the effect of errors on its own.
 
 
 
 In the interest of robustness and clarity of protocol state, the
 
 protocol will include an explicit reply to modification or write
 
 operations even when they fully succeed.
 
 
 
 
 
  Will this cover the architecture document 7.9 transactions impact on
  ephemeral state?
 
 
 
  Sue Hares
 
 
 
  From: Susan Hares [mailto:sha...@ndzh.com]
  Sent: Friday, May 29, 2015 1:44 PM
  To: 'Andy Bierman'
  Cc: 'Juergen Schoenwaelder'; 'Joel M. Halpern'; 'Jeffrey Haas';
  'i2rs@ietf.org'; 'chen@zte.com.cn'; 'Alia Atlas'
  Subject: RE: [i2rs] draft-chen-i2rs-identifier-management-00
 
 
 
  Andy:
 
 
 
  I missed the second part of the email
  (http://www.ietf.org/mail-archive/web/i2rs/current/msg02532.html) in my
  earlier message:
 
 
 
 .  The last paragraph sounds like some nodes will be accepted and others
  rejected.
 
 If any nodes are rejected, the entire edit should be rejected.
 
 
 
  RESTCONF does an atomic action within a http session.   NETCONF within a
  commit.  Section 6.2 of the I2RS architecture document describes state
  storage for I2RS, and it does not have the atomic requirement for the
  protocol.  Instead section 3.3 of the I2RS architecture document calls
 for
  this to be model driver.  Let me provide examples from the 2 major I2RS
  protocol independent models:
 
 
 
  The I2RS RIB yang model (draft-ietf-i2rs-rib-data-model-00)  proposes
 that
  each route will be associated with the following: route preference,
 active,
  installed.  Notifications for route change will be given if route is
  installed, active, and a reason given, or if the route commit fails. Some
  routes may be accepted, and some routes rejected for installation to the
  RIB.   The concept is the client will be able to detect when a route is
  rejected.
 
 
 
  The draft-ietf-i2rs-yang-network-topo-00 states in section 3.5 discusses
 the
  challenge that topology models are not: configuration data only or
  operational data only – but a combination of both in ephemeral state.
  Draft-ietf-i2rs-yang-network

Re: [i2rs] simple rechartering underway

[Alia Atlas]

On Wed, Mar 11, 2015 at 3:55 AM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Wed, Mar 11, 2015 at 03:33:14AM -0400, Alia Atlas wrote:
  Juergen,
 
  On Wed, Mar 11, 2015 at 3:24 AM, Juergen Schoenwaelder 
  j.schoenwael...@jacobs-university.de wrote:
 
   On Fri, Mar 06, 2015 at 06:06:44PM -0500, Alia Atlas wrote:
Given the excellent progress that the WG has been making - due to
 your
   work
and interest, I have been working on a simple rechartering with Sue
 and
  
   Here is the diff related to topology:
  
   -  o The ability to extract information about topology from the
 network.
   -Injection and creation of topology will not be considered as an
   initial work item.
   +  o The ability to extract information about topology from the
 network.
   + These models will be based on a generic topology model to support
   + multiple uses. Injection and creation of topology will not be
   considered
   + as a work item.
  
   The first and third sentences are both about 'reading topology'. Does
   this imply that the generic model will also be limited to 'reading
   topology'? Or will the generic model also allow create topology?
 
  It's an interesting question.  What use-cases do you see where
  writing the topology is appropriate?

 If you want to do service management, you need to describe (configure)
 the desired service topology. This is largely an interface to the
 network manager (called a controller these days).


True - I see that as needing significantly more information, but having a
generic topology model to build upon would be useful.


  If one thinks of reading the topology as reading operational state,
  aren't read-write config and read-only operational recommended to be
  separated in YANG models (at least for now)?

 Yes, we love to separate config state from operational state. But this
 has nothing to do with the scope of the work item added to the I2RS
 charter.


It is relevant if I2RS defines the operational topology for reading and
there
isn't an active need for writing the topology.

If there is an active need - presumably because of interest in modeling
interfaces
to a network manager - then I can massage the text.  I don't see a reason
to have separate drafts.

Alia


 /js

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

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

Re: [i2rs] simple rechartering underway

[Alia Atlas]

Juergen,

On Wed, Mar 11, 2015 at 3:24 AM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Fri, Mar 06, 2015 at 06:06:44PM -0500, Alia Atlas wrote:
  Given the excellent progress that the WG has been making - due to your
 work
  and interest, I have been working on a simple rechartering with Sue and

 Here is the diff related to topology:

 -  o The ability to extract information about topology from the network.
 -Injection and creation of topology will not be considered as an
 initial work item.
 +  o The ability to extract information about topology from the network.
 + These models will be based on a generic topology model to support
 + multiple uses. Injection and creation of topology will not be
 considered
 + as a work item.

 The first and third sentences are both about 'reading topology'. Does
 this imply that the generic model will also be limited to 'reading
 topology'? Or will the generic model also allow create topology?


It's an interesting question.  What use-cases do you see where writing the
topology
is appropriate?  If one thinks of reading the topology as reading
operational state,
aren't read-write config and read-only operational recommended to be
separated in
YANG models (at least for now)?

Alia


 /js

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

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

[i2rs] simple rechartering underway

[Alia Atlas]

Given the excellent progress that the WG has been making - due to your work
and interest, I have been working on a simple rechartering with Sue and
Jeff.

The new proposed charter is at
http://datatracker.ietf.org/doc/charter-ietf-i2rs/.
It adds the ability to work on a filter-based RIB model.
It allows I2RS to work on YANG data models to supports its in-charter
use-cases.
It clarifies that the topology work will be done starting with a generic
topology model.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] I2RS topology is generic?

[Alia Atlas]

Hi Juergen,

On Thu, Mar 5, 2015 at 3:11 AM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Wed, Mar 04, 2015 at 08:01:35PM -0500, Alia Atlas wrote:
 
  Those interested in SUPA were told very clearly before last IETF that
  the topology work was already being addressed in I2RS.  You haven't
  chosen to participate in progressing the actual work.
 

 Some people do read charters to determine what WGs are supposed to do.
 If charters get out of sync, then this leads to mis-understandings. I
 think it is not fair to blame those who read outdated charters.


The charter says topology.  2 years in, we may want to refine what that
means
in the context of how other models are being done.  For instance, TE
topology
is being done in TEAS.   When I2RS started, the topology in the charter
wasn't
further nuanced. Certainly, the idea of exposing service topologies was
discussed.
I haven't seen progress on those aspects.  There has been work on a generic
topology model.  That it is still an individual draft has more to do with
responsiveness
to input - and has been addressed by the current WG chairs.


/js

 PS: I actively tried to bring SUPA folks to I2RS interims where
 topology was on the agenda but then the agenda got changed. This
 is fine, the WG chairs can choose to set priorities. But then
 having to read you haven't chosen to participate in progressing
 the actual work makes me feel somewhat unhappy given that there
 is a design team and attempts to figure out what is going on in
 the past did not work out.


The design team started since November.  The I2RS mailing list is a fine
place for discussing technical ideas and considerations to progress the work
as well as, of course, discussing ones own draft contributions.

Regards,
Alia



 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

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

Re: [i2rs] I2RS topology is generic?

[Alia Atlas]

Hi Benoit,

Yes, as is clearly articulated in the draft,it is a generic topology into
which all other topology-related work should
plug.

I2RS and Alex are very happy to hear comments and reviews of that draft.

Regards,
Alia

On Wed, Mar 4, 2015 at 4:50 PM, Benoit Claise bcla...@cisco.com wrote:

  Dear Alia,

 I would need your guidance. On my side, I'm trying to help the SUPA people
 with the scope of their work.

 During a SUPA call during which Sue explained the I2RS work (thanks again
 Sue), she answered a key question: any topology work should be based on the
 I2RS topology draft (draft-clemm-i2rs-yang-network-topo draft). This draft
 was called the generic topology model draft.

 Discussing further with the SUPA BoF chairs, it was observed that the I2RS
 charter doesn't mention it's a generic topology model. So please let us
 know what your intention is. Is this L3 topology a generic one, into which
 all others topology-related work should plug?

 The SUPA requirement is a way to express topology at several layers of
 abstraction (granularity).

 Regards, Benoit



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

Re: [i2rs] I2RS topology is generic?

[Alia Atlas]

Juergen,

When I2RS recharters, I am certain that I'll hear your input.
I am much less interested in rules-mongering and trying to pick
holes (the lack of generic before an unqualified topology in the
charter) than I am in gathering people who are doing real work on topology
to get it DONE finally.

Those interested in SUPA were told very clearly before last IETF that
the topology work was already being addressed in I2RS.  You haven't
chosen to participate in progressing the actual work.

As for understanding how the IETF works, all the words in the world
don't help if the recipient isn't willing to listen.

Alia




On Wed, Mar 4, 2015 at 6:22 PM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Wed, Mar 04, 2015 at 04:52:14PM -0500, Alia Atlas wrote:
  Hi Benoit,
 
  Yes, as is clearly articulated in the draft,it is a generic topology into
  which all other topology-related work should
  plug.
 
  I2RS and Alex are very happy to hear comments and reviews of that draft.
 

 Alia,

 I like to see this clarified in the charter. The current charter says:

 o The ability to extract information about topology from the
   network.  Injection and creation of topology will not be
   considered as an initial work item.

 If the work of I2RS has been expanded to do generic topology work,
 then I think it is necessary to document that by updating the WG
 charter. Frankly, it seems there is more stuff in the current charter
 that does not seem to reflect the WGs and ADs understanding of what
 I2RS works on. Anyway, pointing to an individual I-D in order to
 define what that scope of the work of I2RS is making it really hard
 for others to understand how the IETF works.

 /js

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

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

Re: [i2rs] I2RS charter: information model or data model (in YANG)?

[Alia Atlas]

Benoit,

On Tue, Mar 3, 2015 at 9:33 AM, Benoit Claise bcla...@cisco.com wrote:

 Dear all,

 The I2RS charter contains:
 Request publication of Standards Track documents specifying
 information models
 The working group is not currently chartered to develop protocols,
 encoding languages, or data models.

 However, the charter is more than two years old: 2013-01-29
 Background: the information model was mentioned in charters in the past,
 as an extra step, while waiting for an emerging data modeling language. In
 the mean time, YANG became the de facto data modeling language.

 Therefore, I believe that the WG should be focusing on YANG data models,
 and skip the information model step.


I agree.  I think the high level of the information model is useful with
the YANG data model.  I'm chatting with Jeff and Sue about updating the
charter to clarify this fairly quickly.

Regards,
Alia




 Regards, Benoit






 ___
 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

Re: [i2rs] I2RS interim on 2/5/2015 at 10:00am - 11:00 ET

[Alia Atlas]

There was confusion with different webex sessions.
The meeting is happening on the webex in this email - not what was in, at
least, my calendar.

It's

*Join WebEx meeting*
https://ietf.webex.com/ietf/j.php?MTID=meafefc64f2e80902d4d364851f42ab61


Meeting number:

640 334 334

On Thu, Feb 5, 2015 at 10:09 AM, Giles Heron giles.he...@gmail.com wrote:

 is there a time-zone mixup with this?

 the invite below says 10am EST.   I suspect you meant 10am PST - given
 that we have a total of 4 people on the WebEx.

 or maybe nobody (including the chairs) cares about I2RS any more. ;)

 On 5 Feb 2015, at 00:28, Susan Hares sha...@ndzh.com wrote:

  The I2RS interim on 2/5/2015 at 10:00am has the following agenda
 regarding the I2RS protocol
 
  1)  7 primitives that should be exposed from the I2RS Agent  (Dean
 Bogdanovic)
  2)  Discussion on 7 primitives
 
  Our discussion on the I2RS protocol are aimed at providing requirements
 for the I2RS protocol.
 
  Our past discussion have considered a smaller protocol and the use of
 netconf/restconf for full functionality.  Dan’s presentation is considering
 what has to be in a protocol – small or large.  The I2RS goal is to
 consider these requirements and finalize an I2RS protocol requirements
 document in February that will be discussed for WG adoption in IETF 92.
 
  For those who have proposed a protocol requirements in the past, and
 would like to join a design team completing the I2RS protocol requirements
 please esnd me a note.
 
  Sue
 
  From: I2RS Working Group [mailto:messen...@webex.com]
  Sent: Wednesday, February 04, 2015 7:16 PM
  To: i2rs-cha...@tools.ietf.org
  Subject: (Forward to others) WebEx meeting invitation: I2RS Interim
 
  You can forward this invitation to others.
  Hello,
  I2RS Working Group invites you to join this WebEx meeting.
 
  I2RS Interim
  Thursday, February 5, 2015
  10:00 am  |  Eastern Standard Time (New York, GMT-05:00)  |  1 hr 30 mins
 
  Join WebEx meeting
  Meeting number:
  640 334 334
  Meeting password:
  smallandbig
 
  Join by phone
  1-877-668-4493 Call-in toll free number (US/Canada)
  1-650-479-3208 Call-in toll number (US/Canada)
  Access code: 640 334 334
  Toll-free calling restrictions
 
  Add this meeting to your calendar.
 
  Can't join the meeting? Contact support.
 
  IMPORTANT NOTICE: Please note that this WebEx service allows audio and
 other information sent during the session to be recorded, which may be
 discoverable in a legal matter. By joining this session, you automatically
 consent to such recordings. If you do not consent to being recorded,
 discuss your concerns with the host or do not join the session.
 
  WebEx_Meeting.ics___
  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

Re: [i2rs] [RTG-DIR] Routing directorate review of draft-ietf-i2rs-problem-statement

[Alia Atlas]

Eric,

Ok.  Done and posted as version -06.

Thanks,
Alia

On Wed, Jan 7, 2015 at 4:09 PM, Eric Gray eric.g...@ericsson.com wrote:

  Alia,



 I’m happy with not changing the text further in section 5
 and I would

 appreciate it if you make the minor change to the introduction.



 So it looks like we have converged…



 --

 Eric



 *From:* Alia Atlas [mailto:akat...@juniper.net]
 *Sent:* Wednesday, January 07, 2015 3:55 PM
 *To:* Eric Gray; Alia Atlas
 *Cc:* rtg-...@tools.ietf.org; rtg-...@ietf.org;
 draft-ietf-i2rs-problem-statem...@tools.ietf.org; i2rs@ietf.org
 *Subject:* RE: [RTG-DIR] Routing directorate review of
 draft-ietf-i2rs-problem-statement
 *Importance:* High



 Hi Eric,



 Responses in-line below (but with agreements removed).

 I’ll push out the slightly modified version as soon as I hear back from
 you.



 Thanks again,

 Alia





 *From:* Eric Gray [mailto:eric.g...@ericsson.com eric.g...@ericsson.com]

 *Sent:* Wednesday, January 07, 2015 11:14 AM
 *To:* Alia Atlas
 *Cc:* rtg-...@tools.ietf.org; rtg-...@ietf.org;
 draft-ietf-i2rs-problem-statem...@tools.ietf.org; i2rs@ietf.org
 *Subject:* RE: [RTG-DIR] Routing directorate review of
 draft-ietf-i2rs-problem-statement



 Alia,



 Hope everyone enjoyed the holidays.



 Responses in-line *below*…



 *From:* Alia Atlas [mailto:akat...@gmail.com akat...@gmail.com]
 *Sent:* Tuesday, January 06, 2015 5:29 PM
 *To:* Eric Gray
 *Cc:* rtg-...@tools.ietf.org; rtg-...@ietf.org;
 draft-ietf-i2rs-problem-statem...@tools.ietf.org; i2rs@ietf.org
 *Subject:* Re: [RTG-DIR] Routing directorate review of
 draft-ietf-i2rs-problem-statement
 *Importance:* High



 Hi Eric,



 Thanks for your review.  I really appreciate it.

 On Tue, Dec 16, 2014 at 8:33 PM, Eric Gray eric.g...@ericsson.com wrote:

 Hello,

 I have been selected as the Routing Directorate reviewer for this draft.

 The Routing Directorate seeks to review all routing or routing-related
 drafts as they pass through IETF last call and IESG review, and sometimes
 on special request.

 The purpose of the review is to provide assistance to the Routing ADs.

 For more information about the Routing Directorate, please see:

 ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

 Although these comments are primarily for the use of the Routing ADs, it
 would be helpful if you could consider them along with any other IETF
 Last Call comments that you receive, and strive to resolve them through
 discussion or by updating the draft.

 Document: draft-ietf-i2rs-problem-statement
 Reviewer: Eric Gray
 Review Date: 12/16/2014
 Intended Status: Informational

 Summary: I have some minor concerns about this document that I think
 should be resolved before before publication.  The document has nits
 that should also be considered prior to publication.

 Minor Issues:
 ==

 Section 5 title is Desired Aspects of ... but the first sentence talks
 about
 required aspects ...  I believe that the authors should be consistent.



 Keeping required



 The actual key aspects needed are a mixture or required and desired
 behaviors.  Because the draft does not refer to RFC 2119 terminology,
 it is not clear if this is intended or a result of narrative style choices.



 I'm not sure which ones you are reading as desired vs. required.  The
 intent

 is that all are required; trade-offs do happen.



 *Changing the section title helps.  The issues that remain are less
 significant*

 *when considered as “aspects to be considered.”*



 *I wanted to avoid being pedantic, but one example (now more minor) is as*

 *follows:*

 -  *1st paragraph uses the phrase “describes required aspects”*

 -  *the 1st list item (multiple simultaneous asynchronous
 operations),*

 *however, says that a single application should be able to …*



 I am well used to pendatry ;-)



 *Without the reference to RFC 2119, “should” may be ambiguously
 interpreted*

 *according to standard English as something likely but not required.*



 *I think what was probably meant in this case is that protocol is required
 to*

 *support applications that perform multiple concurrent operations (which
 is*

 *something we believe applications should be able to do).*



 *The current text is not explicit about this as a protocol requirement, if
 that is *

 *what is intended, instead making the protocol requirement implicit based
 on *

 *the way that we believe applications would likely use it.*



 *There are similar issues with “High Throughput”, “Low Latency” and
 “Multi-*

 *Channel.”*



 *One advantage of referring to RFC 2119 is it makes “should” less
 ambiguous,*

 *and defines this term (and other terms) as “requirement levels.”*



 *But I am okay with leaving this as is, because of the heading change.
 Most*

 *people will be able to figure out what is meant, eventually.  **J*



 I think so also.   This is describing what the solution

Re: [i2rs] Gen-ART review of draft-ietf-i2rs-problem-statement-04

[Alia Atlas]

Hi Russ,

Thanks for the review.  Responses in-line.

On Fri, Dec 12, 2014 at 9:53 AM, Russ Housley hous...@vigilsec.com wrote:

 I am the assigned Gen-ART reviewer for this draft. For background on
 Gen-ART, please see the FAQ at
 http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq.

 This review is in response to a request for early Gen-ART review.

 Document: draft-ietf-i2rs-problem-statement-04
 Reviewer: Russ Housley
 Review Date: 2014-12-11
 IETF LC End Date: unknown
 IESG Telechat date: unknown

 Summary: Almost Ready.

 Major Concerns:

 Section 5 says, Data written can be owned by different I2RS clients.
 The intended consequences are unclear.  I assume that the data written
 by one client cannot be rewritten by another client.  However, I can
 imagine some situations where the same data object might be written by
 more than one client at different times.  Please add some language to
 say whether this situation is within scope or not.


It is possible for the same data object to be written by more than one
client
at different times; conflicts are resolved by priority.   The details of
how this
are handled are described in draft-ietf-i2rs-architecture, which, quite
reasonably,
you many not have read.

I have changed the text to read:


 Data written can be owned by different I2RS clients at different times;
data
may even be overwritten by a different I2RS client.  The details of how this
should be handled are described in [draft-ietf-i2rs-architecture].


Section 5 includes a requirement for multi-channel.  I would expect
 policy to dictate that some requests, especially ones that impact the
 whole router, come from a specific source.  This might require that
 the request arrive on a particular port or that it be authenticated in
 a particular manner.  Can more be said about the policy controls here?


In the problem statement?  We do have Secure Control: Any ability to
manipulate routing state must be subject to authentication and
authorization.
Such communications must also have its integrity protected

It's important for most writable state.  I could add a reference to the
architecture
again, but I'm not convinced that it is needed.  These are different
aspects that
need to pull together into a single protocol - and the secure control with
associated
policy is definitely part of that.


 Section 8 seems very thin to me.  There are some lessons from MIBs
 documented here: www.ops.ietf.org/mib-security.html.  I think that
 some of this extrapolates to this document, but I do not think that
 a pointer to those guidelines is the best way forward.


You are right.  I will add a reference to draft-ietf-i2rs-architecture,
which has an
extensive section discussing security.  I've pulled a couple key concepts
from there
as well - since I think they are worth highlighting.

Security is a key aspect of any protocol that allows state
  installation and extracting of detailed router state.  The
  security considerations are discussed in
[draft-ietf-i2rs-architecture].
  Briefly, the I2RS Agent
  is assumed to have a separate authentication and authorization
  channel by which it can validate both the identity and the
  permissions associated with an I2RS Client.  Mutual
  authentication between the I2RS Agent and I2RS Client is
  required.  Different levels of integrity, confidentiality, and
  replay protection are relevant for different aspects of I2RS.

Minor Concerns:

 The document talks about the IESG statement issued on 2 March 2014.
 Please add a reference, which is probably best done with a URL.


Done


 Section 5 says that the ability to manipulate routing controls is
 subject to authentication and authorization.  This is highly desirable.
 Can we go a little bit further?  Is it like root on a Unix box, or is
 the authorization more granular?  Are there known roles that must be
 supported?


It is intended to be more granular and the expectation is that there are
multiple roles - but the details of those roles aren't defined in the
problem-statement
or even the architecture.  Given the updated security considerations
section,
I'd rather not specify too much here.


 Other Comments:

 Section 5 says: Such communications must also have its integrity
 protected.  I do not know how to do authentication without also
 providing integrity, so this is really implied by the previous
 sentence.  That said, I suggest the following wording: Such
 communications must be integrity protected.


Sure - change made.

I'll publish an updated version very soon (today/tomorrow) after I've dealt
with
outstanding comments.

Thanks again for your review!
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

[i2rs] updated draft-ietf-i2rs-problem-statement-05

[Alia Atlas]

I have posted an updated version that I believe responds to all the
various reviews that I saw (GenArt, RtgDir, SecDir, Shepherd).

Please send any comments and concerns about the new version to
the list as well as me.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Call for IPR infromation for I2RS Problem statement and I2RS Architecture document

[Alia Atlas]

no hats on
I do not know of any IPR on either of these drafts.

Alia

On Wed, Dec 3, 2014 at 1:02 PM, Susan Hares sha...@ndzh.com wrote:

 I2RS WG:



 This is a 1 week call (12/3 – 12/10) for any IPR related to the I2RS
 problem statement and architecture drafts.  These drafts have passed WG LC,
 and the current versions can be found at:



 http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/



 http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/



 We would appreciate if the authors of the drafts would respond to this
 query on the mail list even if you have responded to Jeff Haas and Ed
 Crabbe earlier.



 Thank you,



 Sue Hares and Jeff Haas



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

[i2rs] I2RS co-chair

[Alia Atlas]

To confirm what I said in this meeting...

Ed is stepping down.  Thank you, Ed, for all that you've done for I2RS.

The ADs have asked Sue Hares to step in as co-chair to work with Jeff.

I've asked the Secretariat to make this change as soon as possible.

Thanks,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

On Mon, Oct 6, 2014 at 9:32 AM, Jeffrey Haas jh...@pfrc.org wrote:

 On Fri, Oct 03, 2014 at 05:43:27PM -0400, Alia Atlas wrote:
  Now - if we have to decide that the CLI always wins, that is one option.
  I, personally, would be quite opposed to the idea that I2RS would always
  win.  That does not give recovery mechanisms to the operators when and
  if something goes wrong.

 So, what is your proposal to allow CLI/local config to win over ephemeral
 state?  If not something comparable to option 4, what then?


Jeff,

It's a good question.  I have been sweeping it under
implementation-specific
since it is up to an implementation to decide what collides.  If we were
talking about
vendor-specific CLI vs. YANG models for I2RS, how would it work?  At the
end of
the day, there has to be understanding of what internally is impacted.

I can picture different abstractions or subsets being exposed for I2RS
rather than
CLI or NetConf-for-config.  I do go more towards Russ's idea of I2RS as a
routing
protocol that cooperates with the other routing protocols rather than just
another name
for a management protocol.

Regards,
Alia


 -- Jeff

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

[i2rs] Creation of rtg-yang-coord mailing list

[Alia Atlas]

The rtg-yang-coord mailing list will provide a forum for coordination of
the development  of YANG models being worked on for Routing, in order to
provide a consistent view to the NMS.  The intended participants are people
active in Routing working groups and interested in the associated YANG
models, and YANG experts assisting with Routing YANG models. While this
list will help with the synchronization, WGs with responsibility for
core routing protocols are expected  to also be responsible for the
development of YANG models for those  protocols.

To subscribe, visit:

https://www.ietf.org/mailman/listinfo/rtg-yang-coord

Regards,

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

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

Hi Dean,

Sorry for the delay in responding.  Telechats do that to one.

On Wed, Oct 1, 2014 at 10:12 AM, Dean Bogdanovic de...@juniper.net wrote:


  On Oct 1, 2014, at 9:54 AM, Alia Atlas akat...@gmail.com
  wrote:

  Hi Dean,

  Thanks for the explanation.  It matches with what I understand for
 configuration.
 Where I am confused is why I2RS - which is doing ephemeral only and
 matches closer to the direct proprietary APIs directly to
 the routing processes - is being tied up in this.


  Today there is no standard protocol to expose writing to the daemons
 directly, except through a datastore. If you would compare routing daemon
 in Junos and routing daemon in IOS or NX-OS, the data models are very
 different. You need a standard API to communicate to all of them.


Right - but that's what I2RS is asking and trying to do.  I'm sure I didn't
just hear you say that we can't do it because it doesn't exist yet.


  Here is a reason why a local datastore comes handy

  routing daemon crashes and the state is gone. The routing state has to
 be reinstated.

  1. replay config data from the local data store(s) and reactivate the
 configuration
 2. replay config data from the local data store (single data store) and
 request all I2RS clients to replay their data again

  Now if some I2RS client, during the crash, tried to execute routing
 changes, with local store, those can be executed and put into wait state
 until daemon recovers. I2RS clients can be informed that their changes are
 pending.


I do understand that a datastore is useful for config.  For I2RS, if the
relevant routing crashes, then the I2RS clients are just notified that
their state is gone.  If an I2RS client tries to request a change and the
routing daemon isn't up, then the change fails!  This is part  of being in
a dynamic and distributed system.


  Both approaches have pluses and minuses.

  Another issue is  with config statements. If you go directly to the
 daemons, only few very basic things can be exposed (like interfaces,
 routes, stateless fw filters). If you want to expose more complex
 statements like L3VPN, then you have to create a logic that will
 communicate to multiple daemons to create such state on the device. You are
 doubling such logic on the device.


Right - but here I have to pull our attention back to the charter.  We can
do:
   RIB, topology (read only), BGP, DDOS mitigation, hub-and-spoke routing
improvement, and traffic exit point optimization.

If there are proprietary mechanism for everything else, that's ok.  Let's
get this designed correctly - given the WG agreement on the architecture
and the charter constraints on the use-cases.

 I want to allow network administrators to decide by them self what is
 exposed through I2RS, not us (vendors, SDOs).


Then we boil the ocean, claim everything is safe, try and solve all the
hard problems instead of taking reasonable efforts with the simple parts
first.

Let's get something done that can be implemented.

Regards,
Alia



  Dean


  Regards,
 Alia

 On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic de...@juniper.net wrote:

 Hi Alia,

 today networking devices can be managed in three ways:

 1. CLI - is the UI we all know and use it quite heavily. In order for the
 device to boot in a known state a set of CLI commands have to be saved
 somewhere on the device. For that you have a data store. That data store
 can be a flat file or a database. The datastore is then read by network
 device daemons which change their state based on it.

 Before the APIs were exposed, TCL/Expect and Perl ruled the automation
 world and everything was based on screen scraping. In order to make machine
 to machine communication easier, NETCONF was created as a standard protocol
 to communicate with the devices.

 2. via APIs - there are several type of APIs, but most widely available
 ones are providing functionalities same as CLI. The difference is that CLI
 is human intended and APIs are machine intended. One of the example is
 Junos XML APIs, where (almost) each CLI command is represented by XML API.
 It still requires knowing how to configure device via CLI and the result of
 the application written with such APIs is stored in the data store from
 which daemon read how to change their state.
 There are some vendors that provide APIs that allow communication with
 daemons directly, bypassing management infrastructure, but those are highly
 proprietary mechanisms.
 The APIs that were released by vendors, were not standardized and each
 vendor had different configuration models, so although communication with
 devices was standardized, there was no easy way to communicate semantics,
 which led to YANG, as standard language that all vendors would understand
 and now standardizing configuration and operational model, so same
 configuration statement can be sent to all supporting devices and be done
 (instead of writing same desired functionality in several configuration
 statements

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

On Wed, Oct 1, 2014 at 10:13 AM, Jeffrey Haas jh...@pfrc.org wrote:

 On Wed, Oct 01, 2014 at 09:54:12AM -0400, Alia Atlas wrote:
  Thanks for the explanation.  It matches with what I understand for
  configuration.
  Where I am confused is why I2RS - which is doing ephemeral only and
 matches
  closer to the direct proprietary APIs directly to
  the routing processes - is being tied up in this.

 The annoying fact is that we have to reconcile what we want to do with the
 semantics of existing netconf/yang.


We do?  I agree that NetConf/RestConf/YANG are the bases that the WG wants
to use
to build I2RS.  I don't think that anyone has the idea that they match
perfectly or
wouldn't need modification for this use.


 The property of being able to override some bit of local config with
 ephemeral config implies at least another data store in those semantics.
 Otherwise you'd have to redefine the existing semantic as a given writer
 may SET a value of a higher visibility priorty and it's allowed to go away
 and reveal the original value of lower visibility priority.


We had that semantic initially (I forget which draft) - and there was
serious WG
pushback that it was too complicated.

I think that a LOT of this simplifies if you make one of two assumptions.
Either
the CLI/NetConf-for-config overrides I2RS or I2RS overrides the
CLI/NetConf-for-config.

If I2RS is lower priority than CLI/NetConf, then when config comes in, any
I2RS
state is preempted and the appropriate I2RS client is notified.  If I2RS
overrides,
then when I2RS state comes in, the associated CLI state is deleted.  I
grant that
the latter case is more complicated - and I'd be really surprised to see
implementations
that were comfortable going there yet.

Regards,
Alia

This makes sense as a merge/patch operation, but less so with a single
 object store.

 -- Jeff

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

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

Hi Igor,

On Wed, Oct 1, 2014 at 1:31 PM, Igor Bryskin ibrys...@advaoptical.com
wrote:

 Alia,

 Your question makes sense if I2RS is limited to routing data manipulation.
 In this case it could be thought of as an additional routing
 protocol.After all OSPF does not need any data store to install its routes,


Exactly - and that is what I2RS is chartered to do.


 What if I2RS client want to configure other things?


I'd like to see us crawl and get the basics right instead of trying to do
everything.
Different mechanisms may apply and be relevant.

Regards,
Alia

Igor
 
 From: i2rs [i2rs-boun...@ietf.org] on behalf of Alia Atlas [
 akat...@gmail.com]
 Sent: Wednesday, October 1, 2014 9:54 AM
 To: Dean Bogdanovic
 Cc: i2rs@ietf.org
 Subject: Re: [i2rs] Why do we need a datastore?

 Hi Dean,

 Thanks for the explanation.  It matches with what I understand for
 configuration.
 Where I am confused is why I2RS - which is doing ephemeral only and
 matches closer to the direct proprietary APIs directly to
 the routing processes - is being tied up in this.

 Regards,
 Alia

 On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic de...@juniper.netmailto:
 de...@juniper.net wrote:
 Hi Alia,

 today networking devices can be managed in three ways:

 1. CLI - is the UI we all know and use it quite heavily. In order for the
 device to boot in a known state a set of CLI commands have to be saved
 somewhere on the device. For that you have a data store. That data store
 can be a flat file or a database. The datastore is then read by network
 device daemons which change their state based on it.

 Before the APIs were exposed, TCL/Expect and Perl ruled the automation
 world and everything was based on screen scraping. In order to make machine
 to machine communication easier, NETCONF was created as a standard protocol
 to communicate with the devices.

 2. via APIs - there are several type of APIs, but most widely available
 ones are providing functionalities same as CLI. The difference is that CLI
 is human intended and APIs are machine intended. One of the example is
 Junos XML APIs, where (almost) each CLI command is represented by XML API.
 It still requires knowing how to configure device via CLI and the result of
 the application written with such APIs is stored in the data store from
 which daemon read how to change their state.
 There are some vendors that provide APIs that allow communication with
 daemons directly, bypassing management infrastructure, but those are highly
 proprietary mechanisms.
 The APIs that were released by vendors, were not standardized and each
 vendor had different configuration models, so although communication with
 devices was standardized, there was no easy way to communicate semantics,
 which led to YANG, as standard language that all vendors would understand
 and now standardizing configuration and operational model, so same
 configuration statement can be sent to all supporting devices and be done
 (instead of writing same desired functionality in several configuration
 statements)

 At the end it really doesn't matter how you are communicating with the
 devices, it really boils down to that you want the device to boot into a
 known state. This was done by having a local data store that was containing
 set of instructions what state the device should be after reading it.

 It really doesn't matter which mechanism is used (from above 2),
 configuration data has to be provided. Historically, data was on the
 device, as the connection between device and the network management was
 slow. Today (like in MSDC), devices don't have local configuration, those
 devices when boot look for provisioning system and get configuration from a
 remote location and then change the state of the device based on it. This
 has led that

 3. some vendors use Linux, allow management via pseudo file system (/proc)

 where the state of the device is changed directly without having a need
 for data store on the device. You have to keep in mind that only Linux
 allows changing the state of non-processes data through /proc. *BSD flavors
 don't allow that.

 So today, most network operators (by this I mean any entity that operates
 a network, either enterprise or carrier), need to simplify network
 management, make it more efficient and that devices will behave very
 predictably, so that network is in a known state. Because of the legacy,
 this is easiest done by having a local datastore on a device, through which
 the state of the device is changed.

 Hope this helps

 Dean


 On Oct 1, 2014, at 12:25 AM, Alia Atlas akat...@gmail.commailto:
 akat...@gmail.com wrote:

  Hi,
 
  I'd like to really understand why I2RS needs a datastore and what that
 actually means.
  In my initial conception of what an I2RS agent would do for, say,
 writing a route in the RIB
  model, is that  the I2RS agent would simply parse a received request
 from a standard format
  and model

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

On Wed, Oct 1, 2014 at 3:23 PM, Thomas D. Nadeau tnad...@lucidvision.com
wrote:


 On Oct 1, 2014:11:15 AM, at 11:15 AM, Andy Bierman a...@yumaworks.com
 wrote:



 On Tue, Sep 30, 2014 at 9:25 PM, Alia Atlas akat...@gmail.com wrote:

 Hi,

 I'd like to really understand why I2RS needs a datastore and what that
 actually means.
 In my initial conception of what an I2RS agent would do for, say, writing
 a route in the RIB
 model, is that  the I2RS agent would simply parse a received request from
 a standard format
 and model into the internal and pass that to a RIB Manager - just as an
 OSPF implementation
 might install a route to the RIB manager.  An I2RS agent could also query
 the RIB Manager to
 read routes and there'd be events coming out.

 With the introduction of priorities to handle multi-headed writers and
 collision errors, the I2RS agent would need to store what was written by
 which client.

 What benefits and rationale does a YANG datastore add?  Why does using
 one need to be
 standardized?

 I apologize if this seems a naive question, but it's been quite a while
 since I read up on YANG and NetConf/RestConf.


 It is a great question because the datastore is used for 3 reasons in
 NETCONF/YANG.

   1) conceptual container for top-level YANG data nodes
 1a) source parameter for retrieval; target parameter for editing
   2) conceptual container for YANG validation rules for the running
 datastore
   3) conceptual container for access control model


 I don't agree that multiple ephemeral datastores are needed. Support for
 multiple clients
 within 1 datastore is needed.


 That is precisely the point I've been making. We've been making this
 discussion far too complex.


Yes - this does not need to be as complex.



 YANG validation rules for the ephemeral datastore are not interesting,
 just the active
 config (running + ephemeral). The access control model for I2RS is
 different than NETCONF.

 Recent discussion has me confused:

A) Are the YANG modules exactly the same for the running and ephemeral
 datastores?
(Interim decided yes)


 Lets hope so, or we've gone off into the woods...


That is my concern.   I've seen no reasoning beyond wishful thinking and a
desire to allow anything to be done quickly and ephemerally.

B) How are the same instances of the same data model related in the
 running and ephemeral
 datastores?

 I thought phase 1 was supposed to be simple and the I2RS client would
 just inject and remove
 RIB data to override the running config.  So, answer to (B) is: datastores
 have independent
 instances. If ephemeral instance exists, it is used. If deleted, then the
 instance from the
 running config (if any) becomes active.  As long as the ephemeral instance
 exists, the running config
 instance is ignored.

 Is this consistent with the architecture document?
 Which solution best fits the agreed upon architecture?





 Regards,
 no-hats  Alia


 Andy



 ___
 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

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

On Wed, Oct 1, 2014 at 3:25 PM, Thomas D. Nadeau tnad...@lucidvision.com
wrote:


 This is where the copy to running config discussion has arrived
 at. We either need a special i2rs operation or just a write to config
 object that can be set and triggers the action.  But by default, the
 changes are ephemeral and thus do not survive reboots.


The initial I2RS framework went down this path of allowing permanent as
well as ephemeral - as you well know - and the WG consensus  was to take it
out as too complex.

Frankly, we're almost 2 years since the BoF and don't have anything that is
implementable.  I think we need to stay simple.

Regards,
Alia



 --Tom


 On Oct 1, 2014:10:45 AM, at 10:45 AM, Igor Bryskin 
 ibrys...@advaoptical.com wrote:

  What if these things must not survive reboots?
  
  From: Thomas D. Nadeau [tnad...@lucidvision.com]
  Sent: Wednesday, October 1, 2014 1:33 PM
  To: Igor Bryskin
  Cc: Alia Atlas; Dean Bogdanovic; i2rs@ietf.org
  Subject: Re: [i2rs] Why do we need a datastore?
 
  On Oct 1, 2014:10:31 AM, at 10:31 AM, Igor Bryskin 
 ibrys...@advaoptical.com wrote:
 
  Alia,
 
  Your question makes sense if I2RS is limited to routing data
 manipulation.
  In this case it could be thought of as an additional routing
 protocol.After all OSPF does not need any data store to install its routes,
  What if I2RS client want to configure other things?
 
 Then just use Netconf or RestConf.
 
 --Tom
 
 
  Igor
  
  From: i2rs [i2rs-boun...@ietf.org] on behalf of Alia Atlas [
 akat...@gmail.com]
  Sent: Wednesday, October 1, 2014 9:54 AM
  To: Dean Bogdanovic
  Cc: i2rs@ietf.org
  Subject: Re: [i2rs] Why do we need a datastore?
 
  Hi Dean,
 
  Thanks for the explanation.  It matches with what I understand for
 configuration.
  Where I am confused is why I2RS - which is doing ephemeral only and
 matches closer to the direct proprietary APIs directly to
  the routing processes - is being tied up in this.
 
  Regards,
  Alia
 
  On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic de...@juniper.net
 mailto:de...@juniper.net wrote:
  Hi Alia,
 
  today networking devices can be managed in three ways:
 
  1. CLI - is the UI we all know and use it quite heavily. In order for
 the device to boot in a known state a set of CLI commands have to be saved
 somewhere on the device. For that you have a data store. That data store
 can be a flat file or a database. The datastore is then read by network
 device daemons which change their state based on it.
 
  Before the APIs were exposed, TCL/Expect and Perl ruled the automation
 world and everything was based on screen scraping. In order to make machine
 to machine communication easier, NETCONF was created as a standard protocol
 to communicate with the devices.
 
  2. via APIs - there are several type of APIs, but most widely available
 ones are providing functionalities same as CLI. The difference is that CLI
 is human intended and APIs are machine intended. One of the example is
 Junos XML APIs, where (almost) each CLI command is represented by XML API.
 It still requires knowing how to configure device via CLI and the result of
 the application written with such APIs is stored in the data store from
 which daemon read how to change their state.
  There are some vendors that provide APIs that allow communication with
 daemons directly, bypassing management infrastructure, but those are highly
 proprietary mechanisms.
  The APIs that were released by vendors, were not standardized and each
 vendor had different configuration models, so although communication with
 devices was standardized, there was no easy way to communicate semantics,
 which led to YANG, as standard language that all vendors would understand
 and now standardizing configuration and operational model, so same
 configuration statement can be sent to all supporting devices and be done
 (instead of writing same desired functionality in several configuration
 statements)
 
  At the end it really doesn't matter how you are communicating with the
 devices, it really boils down to that you want the device to boot into a
 known state. This was done by having a local data store that was containing
 set of instructions what state the device should be after reading it.
 
  It really doesn't matter which mechanism is used (from above 2),
 configuration data has to be provided. Historically, data was on the
 device, as the connection between device and the network management was
 slow. Today (like in MSDC), devices don't have local configuration, those
 devices when boot look for provisioning system and get configuration from a
 remote location and then change the state of the device based on it. This
 has led that
 
  3. some vendors use Linux, allow management via pseudo file system
 (/proc)
 
  where the state of the device is changed directly without having a need
 for data store

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

On Wed, Oct 1, 2014 at 6:18 PM, Andy Bierman a...@yumaworks.com wrote:



 On Wed, Oct 1, 2014 at 3:05 PM, Juergen Schoenwaelder 
 j.schoenwael...@jacobs-university.de wrote:

 On Wed, Oct 01, 2014 at 11:15:40AM -0700, Andy Bierman wrote:
 
  I don't agree that multiple ephemeral datastores are needed. Support for
  multiple clients within 1 datastore is needed.
 

 We can punt this but I believe we will be back discussing this again
 in a couple of years. If multiple clients inject state (in an
 uncoordinated way), certain things will go wrong. If we have no way to
 separate multipe uncoordinated I2RS clients (e.g., by controlling the
 priorities of different ephemeral datastores), then we will need hacks
 with metadata to work around this.


 There are different priorities for clients.
 The collision management and cleanup are basically the same either way,
 because the agent is not required to remember state that got bumped.
 It that were true, then a separate datastore per client would be a feature
 instead of an implementation detail.

 Perhaps it is OK to ignore multiple ephemeral datastores now in order
 to make progress. But I believe we are better off if things are
 designed such that there can be multiple ephemeral datastores when
 they are useful, that is we should not do anything to prevent having
 multiple ephemeral datastores.


 It's hard enough to agree on 1 ;-)

 IMO the ephemeral config always overrides the running config.
 That means in order to remove a static entry from the active config
 (but not the running config), there needs to be an operation
 for creating a data instance deleted entry in the ephemeral datastore.
 (Not a way to have I2RS actually delete entries from the running config).


To quote the I2RS Architecture,

6.3.  Interactions with Local Config

   Changes may originate from either Local Config or from I2RS.  The
   modifications and data stored by I2RS are separate from the local
   device configuration, but conflicts between the two must be resolved

   in a deterministic manner that respects operator-applied policy.
   That policy can determine whether Local Config overrides a particular
   I2RS client's request or vice versa.  To achieve this end, either by
   default Local Config always wins or, optionally, a routing element
   may permit a priority to be configured on the device for the Local
   Config mechanism.  The policy mechanism in the later case is
   comparing the I2RS client's priority with that priority assigned to
   the Local Config.

   When the Local Config always wins, some communication between that
   subsystem and the I2RS Agent is still necessary.  That communication
   contains the details of each specific device configuration change
   that the I2RS Agent is permitted to modify.  In addition, when the
   system determines, that a client's I2RS state is preempted, the I2RS
   agent must notify the affected I2RS clients; how the system
   determines this is implementation-dependent.

   It is critical that policy based upon the source is used because the
   resolution cannot be time-based.  Simply allowing the most recent
   state to prevail could cause race conditions where the final state is
   not repeatably deterministic.

Now - if we have to decide that the CLI always wins, that is one option.
I, personally, would be quite opposed to the idea that I2RS would always
win.  That does not give recovery mechanisms to the operators when and
if something goes wrong.

Regards,
Alia





 /js


 Andy


 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/



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

Re: [i2rs] Why do we need a datastore?

[Alia Atlas]

Hi Dean,

Thanks for the explanation.  It matches with what I understand for
configuration.
Where I am confused is why I2RS - which is doing ephemeral only and matches
closer to the direct proprietary APIs directly to
the routing processes - is being tied up in this.

Regards,
Alia

On Wed, Oct 1, 2014 at 9:39 AM, Dean Bogdanovic de...@juniper.net wrote:

 Hi Alia,

 today networking devices can be managed in three ways:

 1. CLI - is the UI we all know and use it quite heavily. In order for the
 device to boot in a known state a set of CLI commands have to be saved
 somewhere on the device. For that you have a data store. That data store
 can be a flat file or a database. The datastore is then read by network
 device daemons which change their state based on it.

 Before the APIs were exposed, TCL/Expect and Perl ruled the automation
 world and everything was based on screen scraping. In order to make machine
 to machine communication easier, NETCONF was created as a standard protocol
 to communicate with the devices.

 2. via APIs - there are several type of APIs, but most widely available
 ones are providing functionalities same as CLI. The difference is that CLI
 is human intended and APIs are machine intended. One of the example is
 Junos XML APIs, where (almost) each CLI command is represented by XML API.
 It still requires knowing how to configure device via CLI and the result of
 the application written with such APIs is stored in the data store from
 which daemon read how to change their state.
 There are some vendors that provide APIs that allow communication with
 daemons directly, bypassing management infrastructure, but those are highly
 proprietary mechanisms.
 The APIs that were released by vendors, were not standardized and each
 vendor had different configuration models, so although communication with
 devices was standardized, there was no easy way to communicate semantics,
 which led to YANG, as standard language that all vendors would understand
 and now standardizing configuration and operational model, so same
 configuration statement can be sent to all supporting devices and be done
 (instead of writing same desired functionality in several configuration
 statements)

 At the end it really doesn't matter how you are communicating with the
 devices, it really boils down to that you want the device to boot into a
 known state. This was done by having a local data store that was containing
 set of instructions what state the device should be after reading it.

 It really doesn't matter which mechanism is used (from above 2),
 configuration data has to be provided. Historically, data was on the
 device, as the connection between device and the network management was
 slow. Today (like in MSDC), devices don't have local configuration, those
 devices when boot look for provisioning system and get configuration from a
 remote location and then change the state of the device based on it. This
 has led that

 3. some vendors use Linux, allow management via pseudo file system (/proc)

 where the state of the device is changed directly without having a need
 for data store on the device. You have to keep in mind that only Linux
 allows changing the state of non-processes data through /proc. *BSD flavors
 don't allow that.

 So today, most network operators (by this I mean any entity that operates
 a network, either enterprise or carrier), need to simplify network
 management, make it more efficient and that devices will behave very
 predictably, so that network is in a known state. Because of the legacy,
 this is easiest done by having a local datastore on a device, through which
 the state of the device is changed.

 Hope this helps

 Dean


 On Oct 1, 2014, at 12:25 AM, Alia Atlas akat...@gmail.com wrote:

  Hi,
 
  I'd like to really understand why I2RS needs a datastore and what that
 actually means.
  In my initial conception of what an I2RS agent would do for, say,
 writing a route in the RIB
  model, is that  the I2RS agent would simply parse a received request
 from a standard format
  and model into the internal and pass that to a RIB Manager - just as an
 OSPF implementation
  might install a route to the RIB manager.  An I2RS agent could also
 query the RIB Manager to
  read routes and there'd be events coming out.
 
  With the introduction of priorities to handle multi-headed writers and
 collision errors, the I2RS agent would need to store what was written by
 which client.
 
  What benefits and rationale does a YANG datastore add?  Why does using
 one need to be
  standardized?
 
  I apologize if this seems a naive question, but it's been quite a while
 since I read up on YANG and NetConf/RestConf.
 
  Regards,
  no-hats  Alia
 
  ___
  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

Re: [i2rs] Two thoughts on an ephemeral data store

[Alia Atlas]

Hi Alex, Tom, Joel, et al.

(top-posting)  In the initial I2RS framework, we had the ideal of different
data lifetimes as well as being able to have
written state be permanent or ephemeral.  The I2RS WG consensus was very
clear that I2RS should only support
ephemeral state and that is reflected in the architecture.

In the architecture, the configuration interacts with an I2RS Agent based
on the relative priorities of the configuration
and the I2RS client that wrote the state.  An easy example - certainly what
I'd assume to occur while gaining initial
experience - is that the configuration always overrules I2RS Clients.  If
state is written by an I2RS client that depends
on configuration and the configuration is deleted, then the I2RS client's
state is also deleted and the client is notified.
This is what would happen if it were another I2RS client that caused the
change as well.

I'm quite happy to see focused discussion on how we can actually use YANG
for I2RS in the nitty-gritty details, but I am
concerned that what we end up with is what I2RS is rather than a different
animal.

no-hats Alia

On Wed, Oct 1, 2014 at 12:03 AM, Alexander Clemm (alex) a...@cisco.com
wrote:

 Hi, one reply inline, Alex.
 --- Alex

 -Original Message-
 From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of Jeffrey Haas
 Sent: Monday, September 29, 2014 8:03 AM
 To: Joel M. Halpern
 Cc: i2rs@ietf.org; 'Martin Bjorklund'; Eric Voit (evoit); Alexander Clemm
 (alex); 'Andy Bierman'; 'Jeffrey Haas'; Susan Hares
 Subject: Re: [i2rs] Two thoughts on an ephemeral data store

 On Sun, Sep 28, 2014 at 12:20:36AM -0400, Joel M. Halpern wrote:
  If I am reading you correctly, you are saying taht if an I2RS client
  is manipulating data that is stored in the underlying golden store,
  you want that golden store changed.
  I think that won't work for the requirements.  As far as I can tell
  from your proposal, this would result in I2RS changes being stored
  when someone on the CLI does a commit.  Which is not what is wanted.

 I agree with you, Joel.  This doesn't match the semantics the I2RS WG
 wanted.

 ALEX Your understanding is correct.  These are the semantics of the
 proposal.  When the data in the golden store is changed, it is changed.  It
 is the authoritative copy; the changes will be visible in the other
 datastores that reference it / mount it and there is no question which
 values/settings are in effect.  It's not panes of glass semantics where
 which setting is in effect is computed from overlays of the same object
 instance across different datastores.  The semantics are simpler.  If you
 want to have settings that go into effect when something in another
 datastore is deleted etc, you can still achieve that, but you will need to
 reflect that explicitly in the model.  Whether that's a tradeoff you're
 willing to make is I guess subject for discussion.
 /ALEX


  Conversely, a read-through model would seem to work.  Objects which
  have been created / modified in the I2RS store, when read from the
  I2RS store have their I2RS value.  If you attempt to read or reference
  a value that has not been modified in I2RS, you read-through to the
  underlying data store, and see its value.

 Hopefully my most recent example shows this.

 -- Jeff

 ___
 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] Why do we need a datastore?

[Alia Atlas]

Hi,

I'd like to really understand why I2RS needs a datastore and what that
actually means.
In my initial conception of what an I2RS agent would do for, say, writing a
route in the RIB
model, is that  the I2RS agent would simply parse a received request from a
standard format
and model into the internal and pass that to a RIB Manager - just as an
OSPF implementation
might install a route to the RIB manager.  An I2RS agent could also query
the RIB Manager to
read routes and there'd be events coming out.

With the introduction of priorities to handle multi-headed writers and
collision errors, the I2RS agent would need to store what was written by
which client.

What benefits and rationale does a YANG datastore add?  Why does using one
need to be
standardized?

I apologize if this seems a naive question, but it's been quite a while
since I read up on YANG and NetConf/RestConf.

Regards,
no-hats  Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

[Alia Atlas]

Thomas,

On Mon, Sep 29, 2014 at 2:44 PM, Thomas Narten nar...@us.ibm.com wrote:

  It is NOT OK to tell anyone that they should not contribute a draft -
 because
  it may muddy the water
  or for ANY other non-technical reason.  Individual drafts or desire to
 request
  WG adoption do not change
  this.  I do not ever want to see or hear something like this on an IETF
  mailing list.

 Let me defend Acee here a bit and try to chart a course a bit more
 down the middle. When a WG has an effort underway that is intended to
 lead to a WG document (and that is what I read the current design
 team effort to be), it is IMO often not helpful to have yet more IDs
 submitted on the same topic. Rather than complementing the existing
 work towards a concensus result, additional IDs can be a distraction
 and require folk to spend time figuring out how the other ID relates
 to the WG effort. I.e., it's much more constuctive to say here is
 what is defficient in the current model, and here is what I think we
 should do instead. It is much less constructive to have a standalone
 ID that (probably) overlaps with the other IDs and doesn't focus on
 the *differences* from the other work that already has a head start.


First, I have been encouraging the routing WGs to work on and consider YANG
models.
I have been quite clear in discussing with Benoit that they should be homed
in the Routing
area and that I don't think it makes sense to create a separate working
group to just work
on YANG models.

Second, the assumption that we have had with I2RS is that it will need
different and possibly
more limited models than would be used for configuration of a particular
protocol.  A reasonable
approach could be doing the I2RS-specific models in I2RS and having them
cross-reviewed in
the relevant protocol working-groups.  This is the path that, as I
understand it, Sue was working on.
It would allow review of the interactions between the different models for
their I2RS aspects (assuming
that the WG believes that there are some).

Third, individuals have been working an individual draft
(draft-yeung-netmod-ospf-01) for an OSPF configuration YANG model.  This
was discussed in OSPF last IETF.  I agree that the updated draft, when
posted, is likely to be an excellent candidate for the OSPF WG.

However, regardless of whom may be working on writing
draft-yeung-netmod-ospf-01 or who may have been going behind the scenes
pushing and encouraging (and I am also quite happy and eager and
encouraging to see good YANG models for routing functionality), this is not
an official design team
effort.

Deliberately writing a competing draft may not be constructive.  That is
not what happened here and
it was the combination of trying to incorrectly privilege an (expired)
individual draft that was written to solve a different problem and asking
for someone  who had done work to produce a draft towards a different
problem that caused me to be extremely displeased.

 I realize that one of the topics of discussion since the netmod interim
has been whether it makes sense to have one YANG model that can be used by
NetConf and I2RS for writing and reading.  However, I have not heard
discussed much less agreed upon that approach in I2RS and it is
inappropriate to presuppose the answer and punt work that it is quite
reasonable to assume (and examine to determine) will move the WG forward.


 It is the case that the IETF mantra is submit a draft, but frankly,
 I think that is a bit of a sound bite that we would do well to not
 spit out as often as we seem to because it too often misses what
 really should happen, namely, how best to contribute to reaching
 consensus in a WG. We have a huge problem today where there are
 overlapping/competing drafts that WGs have to sort through. And in
 many of those cases, additional IDs have very little additional
 content than what already exists. But since we go around telling folk
 to submit an ID, we shouldn't be surprise that we get them beyond
 the point of diminishing returns. (And I am NOT saying that the draft
 at issue here is one of those.)


Please let's not try to conflate one specific case with its own concerns
with
generalities.  That is not constructive.


 In this case (and I personally don't have any skin in the game), it
 seems to that both parties are making honest efforts to do the right
 thing, but unfortunately, the state of play was not fully known to all.


Yes, this is communication and clear communication is needed.



  Very very few drafts start perfect and different models have
  different perspectives.  The IETF has a consensus process, as you
  well know of course, to resolve differences between perspectives and
  drafts.

 I didn't hear anyone say that consensus has already been called.  My
 take away is that we have a WG making an honest effort to move forward
 in a particular direction and it is doing exactly what it should be in
 terms of getting behind a design team effort. And IMO, once 

Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

[Alia Atlas]

On Mon, Sep 29, 2014 at 5:41 PM, Acee Lindem (acee) a...@cisco.com wrote:



   From: Alia Atlas akat...@gmail.com
 Date: Monday, September 29, 2014 at 5:33 PM
 To: Acee Lindem a...@cisco.com
 Cc: Thomas Narten nar...@us.ibm.com, Jeff Haas jh...@pfrc.org, 
 i2rs@ietf.org i2rs@ietf.org, Susan Hares sha...@ndzh.com
 Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status
 reports?

   Acee,

 On Mon, Sep 29, 2014 at 4:49 PM, Acee Lindem (acee) a...@cisco.com
 wrote:

 Thanks Much Thomas! Given that I was the victim of considerable back-door
 escalations and machinations, I was giving myself a ³cooling off² period
 prior responding. However, you expressed my sentiments with much more
 patience than I could have myself. Moving forward, we are going to have to
 agree on a home for these protocol models drafts. Of course, my preference
 would be to keep them in the protocol WGs with I2RS and I2RS review. Given
 the IESG statement on YANG models replaced MIBs
 (http://www.ietf.org/iesg/statement/writable-mib-module.html), I had
 viewed this as self-evident.


  First, I really appreciate that you gave yourself a cooling-off period
 before responding.
 I did exactly the same thing before responding.  The last thing that is
 needed or desired
 is escalations.  I think this is an excellent practice when email
 conversations get heated.

  Second, what I have been encouraging is absolutely that the YANG
 configuration models
 should go to each protocol group.  What is confusing the situation here is
 that the I2RS related
 models are not/have not been assumed to be the same thing.  Instead, the
 assumption has been
 that they would be more limited and perhaps have I2RS specifics (such as
 for events) - and
 therefore would happen in I2RS and also be discussed in the specific
 protocol WG.

  Third, there was discussion on the mailing list and at the interim about
 option 4 which is
 pushing I2RS to use exactly the same YANG models.  I have seen discussion
 trying to understand
 what this would look like but certainly nothing around consensus that that
 should be the case.


  I would hope that we have a single model for NETCONF and I2RS or at
 least a core OSPF model that contains the large intersection.


Yes, one of the things that Jeff has been actively working on is
coordination between models, understanding what should be groups for reuse,
etc.  The desire to have a large intersection defined only once is part of
why getting good IM/DM from the I2RS perspective is really useful too.

For something like the RIB DM, it's easy to talk about events
(active/inactive, etc) that one doesn't see or expect in a non-I2RS model.
Whether we have the similar events and other examples for OSPF is the
question.


 My strong reaction and email was to several things that I saw happening
 together:
 a) Efforts to privilege an individual draft (expired) and push away
 other approaches.  I do understand that it was very well received last
 IETF, that a new version will be out soon, and that you can't ask for WG
 adoption in OSPF until that occurs.
 b) A claim that the draft targeted at a config model for OSPF was all
 that was needed for I2RS (prejudging the situation)


  The latest OSPF model includes operational state as well as
 configuration and this is one reason why it has taken a long time to
 publish.


Yes - unfortunate though because I believe that it has changed
significantly from what is published and that makes it basically impossible
to review.  I do know that the authors are trying to get out a new version
very very soon; this isn't trying to push them more.   I look forward to
reviewing it (and I don't say that about many drafts these days).

Regards,
Alia



  Thanks,
 Acee



  I know that we want to get really great YANG models out of this and
 encourage more
 people to work in this space and also want to see I2RS make actual
 progress.

  I also agree that there are better ways for people to collaborate than
 to go away and write a competing draft - but I do not think that was the
 intent or what happened here.

  Regards,
 Alia



 Acee

 On 9/29/14, 2:44 PM, Thomas Narten nar...@us.ibm.com wrote:

  It is NOT OK to tell anyone that they should not contribute a draft -
 because
  it may muddy the water
  or for ANY other non-technical reason.  Individual drafts or desire to
 request
  WG adoption do not change
  this.  I do not ever want to see or hear something like this on an IETF
  mailing list.
 
 Let me defend Acee here a bit and try to chart a course a bit more
 down the middle. When a WG has an effort underway that is intended to
 lead to a WG document (and that is what I read the current design
 team effort to be), it is IMO often not helpful to have yet more IDs
 submitted on the same topic. Rather than complementing the existing
 work towards a concensus result, additional IDs can be a distraction
 and require folk to spend time figuring out how the other ID relates

Re: [i2rs] IETF 91 meeting requested - call for agenda; status reports?

[Alia Atlas]

Acee,

It is NOT OK to tell anyone that they should not contribute a draft -
because it may muddy the water
or for ANY other non-technical reason.  Individual drafts or desire to
request WG adoption do not change
this.  I do not ever want to see or hear something like this on an IETF
mailing list.

Very very few drafts start perfect and different models have different
perspectives.  The IETF has a
consensus process, as you well know of course, to resolve differences
between perspectives and drafts.

Second, a NETMOD interim with tentative ideas on how it might be nice to
carry out requests in an
individual draft  does not in any way dictate how I2RS should proceed.
I2RS is in Routing
because we understand the work and details to be done.  The desire that
there can be only one model for
any and all purposes is interesting but it isn't clear that is feasible.

I d not have any more polite words to discuss this.

Alia

On Sun, Sep 28, 2014 at 12:59 PM, Acee Lindem (acee) a...@cisco.com wrote:

  Sue,

  See inline.

   From: Susan Hares sha...@ndzh.com
 Date: Saturday, September 27, 2014 at 8:21 PM
 To: Acee Lindem a...@cisco.com, Jeff Haas jh...@pfrc.org
 Cc: i2rs@ietf.org i2rs@ietf.org
 Subject: RE: [i2rs] IETF 91 meeting requested - call for agenda; status
 reports?

Acee:



 I think we are still confused. The different streams (i2RS/config) that
 may or may not be merged (under debate).  Both i2rs/config streams had open
 calls at IETF 90 for contributions and collaborators based on pre-IETF 90
 work. On that portion of topic after this message, let’s declare rat hole.



 My key question is still unanswered:  “Do I understand is that you as
 co-chair of OSPF are stating you recommend not reading or reviewing the
 I2RS OSPF drafts I and my-authors created for the I2RS stream and instead
 you recommend figuring out if your existing configuration drafts fit I2RS?”
  I appreciate your bluntness so I can figure where to put our next efforts
 in I2RS.


  Note the IESG statement on YANG models independent of I2RS:

  http://www.ietf.org/iesg/statement/writable-mib-module.html

  We have been working on YANG models for some time in both OSPF and ISIS.
 The ISIS model is already being adopted and we will request WG OSPF
 adoption upon the next refresh. I can’t help it if you are not following
 the WGs for which you are proposing models. For your next efforts, I'd
 recommend better coordination and awareness of WG activities.

  Thanks,
 Acee







 Thank you,



 Sue



 *From:* Acee Lindem (acee) [mailto:a...@cisco.com a...@cisco.com]
 *Sent:* Saturday, September 27, 2014 7:37 PM
 *To:* Susan Hares; 'Jeffrey Haas'
 *Cc:* i2rs@ietf.org
 *Subject:* Re: [i2rs] IETF 91 meeting requested - call for agenda; status
 reports?







 *From: *Susan Hares sha...@ndzh.com
 *Date: *Saturday, September 27, 2014 at 7:22 PM
 *To: *Acee Lindem a...@cisco.com, Jeff Haas jh...@pfrc.org
 *Cc: *i2rs@ietf.org i2rs@ietf.org
 *Subject: *RE: [i2rs] IETF 91 meeting requested - call for agenda; status
 reports?



  Acee:



 Thank you for the pointer to the message in ISIS.  Perhaps since Chris
 just declared consensus Friday the 9/19/14 that he will get around to
 posting these drafts.



 I’m not sure why you are suggesting that these drafts have not been
 previously posted.



 https://datatracker.ietf.org/doc/draft-litkowski-isis-yang-isis-cfg/

 https://datatracker.ietf.org/doc/draft-yeung-netmod-ospf/



 Acee – my message indicates the isis drafts had not been posted as:
 draft-isis-yang-isis-cfg, and that draft-yeung-netmod-ospf was not the ospf
 web page or netmod web page.   It is a polite indication between chairs
 that if this is important .. you might want to catch up with your
 housekeeping.





 To be clear, I understand from your work that you are declaring consensus
 on the yang models for OSPF model based on your knowledge of the private
 multi-vendor design team.



 As you noted, both the presentations at IETF 90 called for participation.
 These design teams are much less private than the OSPF/ISIS IM/DM drafts
 you submitted yesterday.



 Acee – this is simply not true.  See the above information – it had the
 same level of call at IETF 90.



  You are stating at the OSPF chair that those models have the front seat
 in looking at the I2RS models without reading any of the I2RS IM/DM drafts
 we have prepared.



 The work on the OSPF and ISIS YANG models pre-dated the drafts you have
 submitted yesterday by quite some time so I don’t see we should consider
 replacing it.



 Acee – I’m afraid you rare confusing the I2RS work with the configuration
 work.  Only on 9/19/14 at a yang 1.1 interim (no standing with I2RS), was
 there a suggestion these might work.



   Please confirm that I understand this message so that I can determine
 the next steps to take with these drafts.



 Your next step should be to review the OSPF/ISIS drafts.



 Thanks,A

 Acee









 Sue



 *From:* Acee Lindem (acee) 

[i2rs] some thoughts on draft-tp-i2rs-yang-00

[Alia Atlas]

Hi Tom,

First, thanks for writing this draft.  I found the summary of what NetConf
and YANG do to be useful - despite having read through many of the relevant
RFCs.
I think it is also pulling out lots of the questions about what does using
NetConf/RestConf and YANG mean; some of been touched on in various email
threads also, of course.

For the discussion of the meaning of terms like configuration state and
operational state,  I come at this from the perspective of implementing a
protocol - and there, I am used to configuration state being data that is
passed to the process from the netmgmt system.  There's learned state from
elsewhere in the network.   There are statistics or measured state.
 There's physical state (say of an interface).  There can be operational
state - which is sometimes derived from a combination of what was
configured and what the physical state is.  The easiest example is probably
an interface state - which can be admin-down, oper-down, or oper-up.

Personally, I am now much more aware of the use of configuration state and
operational state from the network management perspective - but find that
they are in conflict and inadequately descriptive for the protocol/process
perspective.

In Section 5, it says

It seems likely, to the author, that this logic does not apply to
I2RS operations on operational state, that is the set of data that
I2RS may want to edit will be a subset of the data that is of interest
to I2RS; read-only statistics, for example, will not be in the former
but will be in the latter. From this it follows that while a single,
boolean substatement may be sufficient, and that anything else can be
achieved with filters, it would much simpler and less error-prone for
I2RS to have a further substatement that defines the set of data that
is of interest to I2RS so that such data can be readily retrieved by
an additional NETCONF RPC, get-i2rs perhaps (NETCONF, like YANG, is
extensible).

Such substatements would, like config, apply to all nodes in the
subtree unless overridden.  By analogy with the config substatement,
it would seem likely that an 'edit-data true' node should not appear
under an 'edit-data false' node (although quite why is not clear to
the author).

I quite agree that the set of data that I2RS will want to edit will be
a subset of the data that is of interest to I2RS.  Rather than trying
for a subtree approach where the editable aspect applies to the whole
subtree, I'd pictured more of a read/write/modify attribute so that
logically grouped information doesn't have to be repeated or separated
in the models.

I don't see the same need to pull i2rs state in the same way that
config state is acquired.

In Sec 6, the draft asks:

Will I2RS, having made changes to the operational state of a box,
want to copy those changes to somewhere else, perhaps so that they can
be re-applied at a later time, such as after a reboot, or is the
underlying assumption of I2RS that such changes should be lost at a
reboot?  Will such a copy be required as an audit trail, a check on
what actually happened, given that the changes that I2RS make are
likely to be of higher risk to the integrity of the routing system
than those made via configuration and NETCONF?

My personal opinion for the first question is no - that the changes
made via I2RS are coming from network-oriented applications which will
reimpose the appropriate operations after a reboot or when necessary.

For an audit trail or a check on what actually happened, I can see
wanting to know which client asked for what operation at what time.  I
think of this as an event flow that an auditor/troubleshooting system
could listen to.  I can also see it being provided via syslog; I
suspect that Wes George and Joe Clarke problably have more refined
opinions on how to do this, but I don't see it coming from reading the
compressed set of most recent changes done.

In Sec 6, the draft asks:
Will I2RS also want to create a set of changes on the box, like a
candidate configuration datastore, so that they can be reviewed,
validity checked by YANG logical statements, before they are applied?

I'd be interested in others thoughts, but I really don't think so.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] working group last call: draft-atlas-i2rs-problem-statement

[Alia Atlas]

Hi Robert,

Sorry for the delay and missing these on the first pass!  I really
appreciate that you
took the time to do a careful and thoughtful review.


On Mon, Jun 9, 2014 at 10:42 AM, Robert Raszuk rob...@raszuk.net wrote:

 Regarding draft-ietf-i2rs-problem-statement-01

 I have few minor comments:

 1.
 Figure 1 sort of implies that I2RS client to I2RS Agent is always a
 point to point session. Is this intentional or accidental ? I can
 imagine bunch of I2RS clients feeding agends with pieces of required
 information which only putted together makes sense - is this out of
 scope as too complex ? Or is this what is called multi-headed control
 ?


[Alia] I've certainly only pictured a point-to-point session.  I don't
expect
that the I2RS agent would put together pieces but rather that the I2RS
Clients can send atomic operations.  Together that set might happen to make
up a service, but that wouldn't be realized or dealt with by the I2RS
agent.



 If so It's definition is not that clear. Does multi-headed  just
 means number of independent clients feeding in async mode complete
 information chunks or is that I2RS agent can collect pieces of info
 for a given information and compiles the product itself. My question
 is for the latter mode.


[Alia] I think it is the former


 2.
  In addition to interfaces to the RIB layer,

 Are we always talking about global RIB or also RIB on line cards on
 distributed systems. While former is much easier the latter may help
 with scalability issues.


[Alia] Hmm, in the problem-statement, I think it can be unspecified.  In
general,
I think about the global RIB - but we do have in the RIB model the idea of
different
routing-instances which apply to only particular interfaces.  So -
depending upon
a particular implementation - feeding routes into a routing-instance with
interfaces
on only a single card might help; I think that's going to be implementation
specific,
but the RIB model should be general enough.



 3.
 Pls change [I-D.gredler-idr-ls-distribution]) to
 draft-ietf-idr-ls-distribution


[Alia] Absolutely - thanks for the catch!


 4.
  For applications to have a feedback loop that includes awareness of
  the relevant traffic, an application must be able to request the
  measurement and timely, scalable reporting of data.

 Frankly I am not sure if I like and support the idea of mixing control
 plane and data plane reporting netflow like data on the same I2RS
 channel/session.

 Not questioning the need .. just questioning the approach :)


[Alia] Ah - this is why I keep talking and writing about multiple transport
channels.
So - the control can be on one channel and the data-plane reporting can be
on
another agreed upon channel.  IMHO, I want a way to ship data off the
linecards
without it having to travel up to a central point.


 5.
  While a few of these (e.g. link up/down) may be available via
  MIB Notifications today, the full range is not - nor is there the
  standardized ability to set up the router to trigger different
  actions upon an event’s occurrence so that a rapid reaction can be
  accomplished.

 So I2RS will also define a router's policy language which will allow
 for setting via I2RS protocol conditional behavior upon specific
 network events ? Will it ever ship complete ? Will it require RIB
 redesign by some vendors which today may not have all opaque info
 there ?


[Alia] Well, we may have to have a simple version first - but when there is
a response that wants to happen in a quick fashion, I think that'd help.  I
haven't seen a lot of work on this idea - but I'm happier to have it in the
problem-statement and then we can see.

It's awsome goal and very attractive, but to me it means that this one
 is a bit separate effort which make take much much longer to agreed in
 IETF on then plain I2RS remote control idea.


[Alia] Yes.  The idea was more connected when we had time-based operations.
I do think that thinking about the simplest requirements and use-cases here
would help.  The problem-statement might be a bit aspirational for now...

Thanks again,
Alia



 Thx,
 R.

 On Fri, May 16, 2014 at 11:15 PM, Edward Crabbe e...@google.com wrote:
  Hello all;
 
  Jeff and I would like to start the two week working group last call for
  draft-atlas-i2rs-problem-statement.  The document may be found here:
 
  http://tools.ietf.org/html/draft-atlas-i2rs-problem-statement-02
 
  The editors and authors are advised to try to resolve as many of the
  comments as possible (on the mailing list) as they come in, but not to
  post the new version of the draft until the wglc is closed and the
  comments are resolved.
 
  This working group last call will end on Friday, 5/30/14
 
  best,
 -ed
 
  ___
  i2rs mailing list
  i2rs@ietf.org
  https://www.ietf.org/mailman/listinfo/i2rs
 

 ___
 i2rs mailing list
 i2rs@ietf.org
 

Re: [i2rs] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04

[Alia Atlas]

Given the level of maturity of the security draft, that we put into the
architecture draft
what we think is good guidance without selecting existing mechanisms, and
that we
are trying to finish the architecture draft, do you really see aspects
missing and if so,
precisely what, around the security section?

I don't want to confuse cherry-picking the parts that are needed from an
immature draft
with information that is missing from the architecture.

IMHO, we will need a draft that talks about what protocols can meet the
requirements,
whether there is a mandatory-to-implement, and so on.  That draft may or
may not be
what the efforts at the security draft matures into.

Regards,
Alia


On Wed, Jun 25, 2014 at 9:51 AM, Juergen Schoenwaelder 
j.schoenwael...@jacobs-university.de wrote:

 On Tue, Jun 24, 2014 at 09:50:24AM -0400, Jeffrey Haas wrote:
 
  If you were paying specific attention to the security issues, please also
  review the security draft.
 

 I have been trying to read draft-hares-i2rs-security-01.txt and to
 match it against draft-ietf-i2rs-architecture-04.txt and I have come
 to the solution that we should

 - stop work draft-hares-i2rs-security-01.txt and

 - merge all statements from this I-D that are worth keeping and that
   are not yet part of draft-ietf-i2rs-architecture-04.txt into
   draft-ietf-i2rs-architecture-04.txt.

 There are numerous places where I the documents are inconsistent and
 this should be avoided if all possible and one way of doing this is
 make sure there is only one document talking about I2RS security
 'architecture'. And I do not see a convincing point why the I2RS
 security 'architecture' should not be sufficiently defined in the I2RS
 architecture - in fact I see many good reasons why the whole I2RS
 architecture should be in one document.

 To substantiate my position, I will list several examples that make
 me concerned. But note that this list is not complete.

 * I am concerned about MUST statements in the security document that I
   do not find in the architecture document. Or, if these MUST
   statements are already in the architecture document, then there is
   no point in repeating them in the security document.

 * I am concerned about definitions such as Role in the security
   document that I do not find in the same meaning in the architecture
   document. Furthermore, I am worried about terms like 'routing tree'
   that are not well defined in the security document and do not exist
   in the architecture document. I note that the definition of Role is
   actually inconsistent even within the security document (e.g.,
   3.3. and 3.1).

 * There are concepts in the security document like I2RS identity
   repositories that I do not find in the I2RS architecture.

 * The section 3.2 of the security document gives guidelines that on
   things like that with symmetric keys, sequence numbers which
   increase monotonically could be useful to help distinguishing
   replayed messages. I believe this goes way beyond _architectural_
   concerns and worse it kind of implies that I2RS may invent their
   security protocol instead of using one of the already available and
   well understood security protocols we have.

 * Section 3.3. is messing up the separation of communication security
   and access control. Furthermore, the advice given that data model
   writers should consider whether a client / agent is valid is IMHO
   wrong. It is wrong to encode authorization policies into data
   models.  The security policy must be configurable at runtime by a
   security administrator. There needs to be a separation of policy
   from mechanism.

 * Similar as above, the advice in section 3.4. that IM/DM writers
   must discuss determine whether encryption is a recommendation or
   requirement is wrong. It is the job of the security administrator
   deploying I2RS to answer those questions. All the IM/DM writer can
   reasonably do is to provide guidelines what in particular may need
   protection (this is what we are doing for ~20 years for MIB
   modules).

 * My understanding is that so called stacked I2RS agent-clients in
   broker topologies are left out of scope in the architecture. Why do
   such things pop up in the security architecture? What is the point
   of having an I2RS architecture with a certain scope and then an I2RS
   security architecture with a bigger scope?

 Bottom line is that I strongly prefer if all the security aspects of
 the I2RS architecture are covered in the document that defines the
 I2RS architecture.

 /js

 --
 Juergen Schoenwaelder   Jacobs University Bremen gGmbH
 Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany
 Fax:   +49 421 200 3103 http://www.jacobs-university.de/

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

___
i2rs mailing list
i2rs@ietf.org

Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

[Alia Atlas]

Hi Lada,


On Tue, Jun 24, 2014 at 5:53 AM, Ladislav Lhotka lho...@nic.cz wrote:

[removing fine conversation]


  [Alia] We described the arbitration rules in Section 6.3 of
  draft-ietf-i2rs-architecture-03.

 I guess we have to think about a proper representation of operational
 state and ways for tagging its contents or otherwise signalling what caused
 a particular change.


[Alia] I think that this is actually implementation-dependent and find the
idea of trying to tag operational state to be excessively complex and
downright scary.  IMHO, the interaction needs to be between the config
system and I2RS.



 For instance, if a configured static route is not present in a RIB
 (operational state), it may be because

 - the next hop wasn't reachable when the static route was configured, or

[Alia] I think this is a bad example.  The route can still go in - it's
just not active.  Anyway, that's expected to happen in I2RS.


 - the I2RS agent deleted it.


In that case, the I2RS agent should have notified the config, IMHO.

The NETCONF server should be able to discriminate between these two cases
 because its action (reinstall the route or not)  may depend on it.


With a better example, yes.

Alia


 Lada

 
 
  
   So one module, three trees, an additional YANG substatement for a leaf
   that is writable by I2RS.
 
  Rather than inventing new annotations, I'd rather like to see making
 YANG
  less NETCONF-specific so that it could directly define schema and
  constraints for other datastores such as the one for I2RS.
 
 
  [Alia] Please - I think there are different assumptions...
 
  Regards,
  Alia
 
 
 
  Lada
 
  
   Tom Petch
  
  
6.4.2  o  writing policy information such as interface attributes
   that
are
  specific to the routing protocol or BGP policy that may
   indirectly
  manipulate attributes of routes carried in BGP.
   
   o  writing routes or prefixes to be advertised via the protocol
I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB
 but
   the
I-D goes on to say
 direct modification of the link-state database MUST NOT be
   allowed
(which I have seen on the list w.r.t. the BGP RIB).
   
or
   
8 The interaction of state installed via the I2RS and via a
   router's
configuration needs to be clearly defined.
which again implies that I2RS and C/N/S are writing to the same
   data.
  
   *Maybe.*
  
   In some cases, the overlap with config state will be quite obvious
 and
   your
   observation will strongly hold.
  
   In other cases, I think a better perspective is that I2RS injected
   state is
   effectively like that of another routing protocol.
  
   If you'd like to argue that BGP is effectively the same as C/N/S...
   well, if
   we're talking Flowspec I might agree. :-)
  
The examples of data that can be changed are few, such as
For example, the interaction with OSPF might include modifying the
   local routing element's link metrics, announcing a
   locally-attached
   prefix, ..
which leaves me wondering, do you expect an OSPF YANG model to be
   unable
to change a link metric:-)
  
   Sure.  In a highly dynamic fashion? With a fallback to a default
   config when
   the application is done?
  
   By comparison to some vendor specific features, it's somewhat the
   difference
   between a policy database (config) and the dynamic policy API that
   doesn't
   require a system reconfiguration event.  If you want to point out
 that
   the
   relationship is strong and that the defining differences are shallow
 -
   you
   could very well be right in those contexts.
  
   Again, we don't expect I2RS work to supplant netconf/yang.  We expect
   to
   leverage the work.
  
If I2RS were aiming at a higher level, say specifying policy and
   have
the system translate that into actual config changes I would
   understand
that, but I do not see I2RS going that far, rather when I2RS says
policy, I think it means changing a community (config again) or
 some
such ie more of an implementation detail than a high level
 strategy.
  
   I hesitate to frame it this way, but one example application is a
 form
   of
   SDN.  The front end says provision this VPN to a data model for
 that
   purpose.  The fact that it may go behind the covers via client-agent
   and
   eventually install ephemeral netconf state is an implementation
   detail.
  
   If you want to argue that such a higher level model is simply
 netconf,
   then
   perhaps we should de-charter and do all of the work in that group. I
   was,
   however, under the impression that work for various models was being
   pushed
   to be done in appropriate working groups. :-)
  
   -- Jeff
  
   ___
   i2rs mailing list
   i2rs@ietf.org
   https://www.ietf.org/mailman/listinfo/i2rs
 
  --
  Ladislav Lhotka, CZ.NIC Labs
  PGP Key ID: E74E8C0C
 
  

Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

[Alia Atlas]

Hi Robert,

Thanks for the review.  Comments in-line.


On Mon, Jun 9, 2014 at 11:19 AM, Robert Raszuk rob...@raszuk.net wrote:

 Hi Jeff,

 Late but still few comments on the draft-ietf-i2rs-architecture-03:


 1.
  This I2RS architecture recognizes that the routing
  system and a router’s OS provide useful mechanisms
  that applications could harness to accomplish
  application-level goals.

 What happens if multiple applications have mutually exclusive needs ?
 It is not really an error as applications and clients by design are
 independent. Where is the arbitration to take place ? In I2RS Client,
 in I2RS Agent or in global router's RIB ?


[Alia] Well, each I2RS Client will have a priority that the I2RS Agent uses
to
determine who wins - but we agreed to set the multiple writers of the same
state as an error.

[Alia] I'd argue that the applications are set up by network operators to do
something and having them collide is something that an operator would need
to investigate.   In the meantime, the I2RS system would just assure
predictability
and avoid oscillation.


 2.
 Fundamental question ...

 Is the I2RS protocol communication to take place in-band, out-of-band
 or both of the data plane ? If we are including in-band I presume
 there is serious risk that the information carried within the protocol
 may cause in-band channels to stop working hence the device becomes
 unreachable (at least for the I2RS system).

 It may be good for architecture document to be able to comment on it.


[Alia] Good point.  In Sec 7.2 on Communication Channels, I've added:

I2RS protocol communication can be delivered in-band via the
routing system's data plane.  I2RS protocol communication might be
delivered out-of-band via a management interface.  Depending on what
operations are requested, it is possible for the I2RS protocol
communication to cause the in-band communication channels to stop
working; this could cause the I2RS agent to become unreachable across
that communication channel.



 3.
  Anticipated I2RS Services

 Is OEM hidden within the Dynamic Data  Statistics or is it just
 plain missing ? ;)


[Alia] Hiding - if you have text that you'd suggest, please do.

Thanks for the careful review,
Alia



 Many thx,
 R.


 On Thu, Jun 5, 2014 at 10:29 PM, Jeffrey Haas jh...@pfrc.org wrote:
  Working Group,
 
  The original deadline for comments on WGLC for the problem statement and
  architecture drafts of May 30 has passed with no comment whatsoever.
 
  While we all realize that there's a bit of exhaustion going on with
 regard
  to these drafts, they are a bit of process we simply must get done in
 order
  to fully move forward with our agenda of putting together data models.
 
  We are *NOT* going to hold that work up further - it is clear that there
 is
  consenus to start making that progress.
 
  To assist us with putting this work behind us, please respond to the
  following questions:
 
  http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
  Have you read the problem statement draft?
  Do you think it is ready to be published as a RFC?
  (If no, please respond to the list with issues.)
 
  http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
  Have you read the architecture draft?
  Do you think it is ready to be published as a RFC?
  (Ditto.)
 
  -- Jeff
 
  ___
  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

Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

[Alia Atlas]

Hi Wes,

Thanks for your thoughtful review.  Responses in-line.

Alia


On Mon, Jun 9, 2014 at 1:19 PM, George, Wes wesley.geo...@twcable.com
wrote:

 
 To assist us with putting this work behind us, please respond to the
 following questions:
 
 http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
 Have you read the problem statement draft? yes
 Do you think it is ready to be published as a RFC?

 Yes, but with two relatively minor comments:
 Section 2: It would be useful to clarify the scope of the proposed data
 model. I realize there’s a separate draft for data model, but since this
 is the primary draft that one should read before diving into the gory
 details, some clarity would be helpful. The big diagram includes a lot of
 interfaces and objects that are out of scope for I2RS, but it’s unclear
 to me whether you also mean that all of those would be out of scope when
 it comes to the data model, or if you actually mean that they are simply
 out of scope when referring to which interface we’re trying to build
 between which objects. I think it’s the latter, since you need to
 represent a much larger range of things in the data model than in the
 interface, but you may want to be more explicit in the latter half of
 section 2, as well as replacing “I2RS with something more descriptive in
 the diagram to avoid naming confusion since “I2RS” can mean IETF WG/effort
 OR the actual interface to the routing system and related protocol.


[Alia] Before the diagram at the end of the paragraph, I've added:
 The scope of the data-models used by I2RS extends across the entire
  routing system and I2RS protocol.
and updated the text inside the figure under the block-diagram to say


  --  interfaces inside the scope of I2RS Protocol
  +--+  objects inside the scope of I2RS-defined behavior

  **  interfaces NOT within the scope of I2RS Protocol
  +**+  objects NOT within the scope of I2RS-defined behavior

    boundary of a router supporting I2RS




 Since section 3 discusses MIBs and configuration, a reference to the
 recent statement about writeable MIBs might also be appropriate here as
 one more bolster to the need for a different protocol to do this work.


[Alia]  Ok - I added to the end of that paragraph:

 Additionally, on March 2, 2014, the IESG issued a statement about
Writeable MIB Modules which is expected  to limit creation of future
writeable MIB modules.



 
 http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
 Have you read the architecture draft? yes
 Do you think it is ready to be published as a RFC?
 Yes, again with a couple of comments:

 1.2 - are we considering flow data as a part of dynamic system state and
 available to I2RS, or not? Would be useful to clarify, especially since
 availability of flow data is often limited (not typically stored in large
 amounts on-box), and similarly to the other stats mentioned, may be
 available via other sources.


[Alia]  Good catch - added in flow data to the Dynamic System State:
description
so that the sentence now reads:

Such state may include various counters, statistics, flow
data, and local events.


6.2 - I recommend that you explicitly call out the need to be able to
 review (e.g. via CLI) the changes made by the I2RS agent and its state
 data without a dependency on the client itself. The simplest
 implementation case for making onboard CLI and I2RS agents play together
 is that the router CLI is simply another application that uses the I2RS
 agent in order to represent the necessary information, but I think that
 dependency might be problematic. I think what is needed here is a way to
 verify what is going on with the I2RS agent via separate means, such that
 if the I2RS agent goes insane, I can use another method to figure out what
 its particular psychosis might be. It may not be practical to assume that
 making the onboard CLI a client of the same agent will produce valid
 results. i.e. I may not get a useful answer if I query the I2RS agent
 “tell me why you’re insane” but I might be able to figure out what the
 agent was doing when it went insane if I can get access to the info about
 what actions it took/what data it manipulated once it went insane, or look
 directly at its underlying state database without its “help. I think this
 is a pretty important thing from a traceability and failure management
 perspective.


[Alia]  At the end of Section 6.3, I added

On a routing element, it is critical that there is a way of
reviewing (e.g. via the CLI) the changes made by each associated I2RS
Agent and its state data.  Preferably, this mechanism should use a
different priveleged mechanism other than simply connecting as an I2RS
client to learn the data.  Using a different mechanism should improve
traceability and failure management.

Thanks again,
Alia


 Thanks

 Wes George


 This E-mail and any of its attachments may contain Time Warner Cable
 proprietary information, which is privileged, confidential, 

Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

[Alia Atlas]

Hi Jim,

I would request that you take a look at the various use-cases drafts.  We
did try and pull from those use-cases to motivate the architecture as well.
 I'd be happy to discuss off-line.

Thanks,
Alia


On Tue, Jun 10, 2014 at 8:35 AM, UTTARO, JAMES ju1...@att.com wrote:

 A document clearly stating the reqs would help me understand the need I2RS
 is addressing. I would suggest writing the reqs info doc first

 Jim Uttaro

 -Original Message-
 From: i2rs [mailto:i2rs-boun...@ietf.org] On Behalf Of t.petch
 Sent: Tuesday, June 10, 2014 7:13 AM
 To: Jeffrey Haas; i2rs@ietf.org
 Subject: Re: [i2rs] Working Group Last Call on architecture and problem
 statement drafts (redux)

 Architecture

 After reading this, I struggle to see the point of I2RS:-(  As was said
 two months ago,
 And the basic premise of I2RS is that there are requirements for the
 work that were not addressed properly by the existing configuration
 protocols. 
 but reading Architecture, the examples I see are ones that seem to fall
 within the remit of NETCONF (being config) as and when a suitable data
 model has been defined (e.g. for OSPF or BGP).  Initially I had thought
 of several things that I2RS might do but these have been ruled out,
 either on the  list or in this I-D, so I am left wondering what it is
 that I2RS will do that NETCONF potentially cannot.

 I do find the I-D quite hard to follow as the terminology seems
 inconsistent - the word 'state' is much used but it is unclear to me if
 the term can be given a single definition in this context; and even if
 it can, the word seems an unfortunate choice since the IETF Ops Area has
 given it a precise definition which is at odds with its use here.

 Tom Petch

 - Original Message -
 From: Jeffrey Haas jh...@pfrc.org
 To: i2rs@ietf.org
 Sent: Thursday, June 05, 2014 9:29 PM

  Working Group,
 
  The original deadline for comments on WGLC for the problem statement
 and
  architecture drafts of May 30 has passed with no comment whatsoever.
 
  While we all realize that there's a bit of exhaustion going on with
 regard
  to these drafts, they are a bit of process we simply must get done in
 order
  to fully move forward with our agenda of putting together data models.
 
  We are *NOT* going to hold that work up further - it is clear that
 there is
  consenus to start making that progress.
 
  To assist us with putting this work behind us, please respond to the
  following questions:
 
  http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
  Have you read the problem statement draft?
  Do you think it is ready to be published as a RFC?
  (If no, please respond to the list with issues.)
 
  http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
  Have you read the architecture draft?
  Do you think it is ready to be published as a RFC?
  (Ditto.)
 
  -- Jeff
 
  ___
  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

Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

[Alia Atlas]

Hi Tom,

On Tue, Jun 10, 2014 at 11:25 AM, t.petch ie...@btconnect.com wrote:

  Original Message -
 From: Jeffrey Haas jh...@pfrc.org
 To: t.petch ie...@btconnect.com
 Cc: Jeffrey Haas jh...@pfrc.org; i2rs@ietf.org
 Sent: Tuesday, June 10, 2014 2:41 PM

  Tom,
 
  Thanks for the comments.
 
  On Tue, Jun 10, 2014 at 12:12:35PM +0100, t.petch wrote:
   but reading Architecture, the examples I see are ones that seem to
 fall
   within the remit of NETCONF (being config) as and when a suitable
 data
   model has been defined (e.g. for OSPF or BGP).  Initially I had
 thought
   of several things that I2RS might do but these have been ruled out,
 
  It'd help if you listed the ones in question.  Some of these things
 may be
  part of the work that is left currently out of scope to attempt to
 constrain
  the WG to things we have decided to get done first.  (Don't bite off
 more
  than you can chew.)

 e.g.
 6.2.3.  Reversion In all such cases, the state will revert to what it
 would have been without the I2RS; that state is generally whatever was
 specified via the CLI, NETCONF, SNMP, etc.
 which seems to say that C(LI)/N(ETCONF)/S(NMP) set it to X, I2RS sets it
 to Y then disappears so it reverts to X, for all values of 'it' - i.e.
 'it' is what NETCONF would call config and so could have been set by
 NETCONF, no need for I2RS!


[Alia] If the state couldn't be set via CLI/NETCONF/SNMP etc, then the
state will revert
to the system default or what was dynamically learned (if that was
something safe to
be overwritten).  This is describing what the behavior should be when
written state is
deleted by I2RS - not making a statement on what the scope of the models
are.


 6.3.  Interactions with Local Config Changes may originate from either
 Local Config or from I2RS.
 Taking Local Config to be what NETCONF/YANG calls 'config' then again,
 nothing there it seems that C/N/S cannot do


[Alia] Again - generically changes can originate - but that doesn't mean
that the full scope
will originate from either.  Collisions and interactions are of interest
when they both can.



 6.4.2  o  writing policy information such as interface attributes that
 are
   specific to the routing protocol or BGP policy that may indirectly
   manipulate attributes of routes carried in BGP.

o  writing routes or prefixes to be advertised via the protocol
 I had assume that I2RS might write to an IGP LSDB or BGP Adj-RIB but the
 I-D goes on to say
  direct modification of the link-state database MUST NOT be allowed
 (which I have seen on the list w.r.t. the BGP RIB).


[Alia] Right - because doing so seriously risks breaking the routing
protocol and leading
to incorrect behavior.  Let's crawl before we run a marathon!


 or

 8 The interaction of state installed via the I2RS and via a router's
 configuration needs to be clearly defined.
 which again implies that I2RS and C/N/S are writing to the same data.


[Alia] If C/N/S write to the config which then writes to the operational
data and
I2RS writes to the operational data, what is the final content of the
operational data?
If I2RS can write set A and C/N/S can write set B, saying that A  B overlap
doesn't imply that A == B.



 The examples of data that can be changed are few, such as
 For example, the interaction with OSPF might include modifying the
local routing element's link metrics, announcing a locally-attached
prefix, ..
 which leaves me wondering, do you expect an OSPF YANG model to be unable
 to change a link metric:-)


[Alia] Remember that low latency, high throughput, and asynchronous
operations are
all aspects of what I2RS is facilitating.  There's a big difference between
change one and
change 1000+ in less than a second.

Whereever I look, I struggle to see what I2RS will write that C/N/S will
 not.


[Alia] Personally, I think that I2RS will write lower-level abstractions
(all the details for the
RIB info-model which aren't a standard part of configuration) and subsets
of data that need
to change fast - plus being a good interface for push notifications and
event streams.  If you
are looking for examples, I'd look at the use-cases.


 If I2RS were aiming at a higher level, say specifying policy and have
 the system translate that into actual config changes I would understand
 that, but I do not see I2RS going that far, rather when I2RS says
 policy, I think it means changing a community (config again) or some
 such ie more of an implementation detail than a high level strategy.


[Alia] True - and if I2RS is designed and implemented well, possibly
higher-level abstractions will also
be possible.  We see the start of that at the desire to have a single
abstract link-state topology for reading,
for instance.  The WG is chartered to crawl first and see what's feasible.
 Getting the problem-statement and
architecture out of the way, along with the language and protocol base
selection that has happened, is
likely to open up the ability to seriously 

Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

[Alia Atlas]

Hi Sri,

Thanks for your thoughtful review!  Responses in-line.

On Tue, Jun 10, 2014 at 3:08 PM, Sriganesh Kini sriganesh.k...@ericsson.com
 wrote:




 On Thu, Jun 5, 2014 at 1:29 PM, Jeffrey Haas jh...@pfrc.org wrote:

 Working Group,

 The original deadline for comments on WGLC for the problem statement and
 architecture drafts of May 30 has passed with no comment whatsoever.

 While we all realize that there's a bit of exhaustion going on with regard
 to these drafts, they are a bit of process we simply must get done in
 order
 to fully move forward with our agenda of putting together data models.

 We are *NOT* going to hold that work up further - it is clear that there
 is
 consenus to start making that progress.

 To assist us with putting this work behind us, please respond to the
 following questions:

 http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
 Have you read the problem statement draft?


 Yes.


 Do you think it is ready to be published as a RFC?
 (If no, please respond to the list with issues.)


 Yes.



 http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
 Have you read the architecture draft?


 yes


 Do you think it is ready to be published as a RFC?
 (Ditto.)


 A question in sec 7.8. Second para. There is a sentence starting with The
 mechanism for this is to ... and later it says In order for this approach
 to   The first sentence seems to imply that this is the only mechanism
 allowed by this architecture whereas the second sentence seems to imply
 that this is one possible mechanism and agents can choose other mechanisms
 too. Which one is correct ? I would suggest that the language be updated to
 reflect that.


[Alia]  I think the confusion is that there are two mechanisms - one to
ensure predictability that the I2RS Agent does and one for the I2RS Client
to use to realize when its operations have been preempted.  I've clarified
the The mechanism for this is to to say
The mechanism for ensuring predictability is to have a simple priority
associated with each I2RS clients, and the highest priority change remains
in effect.

Thanks,
Alia


 Otherwise the doc looks good to be published as a RFC.

 Sri



 -- Jeff

 ___
 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] updated draft-ietf-i2rs-architecture-04 and draft-ietf-i2rs-problem-statement-04

[Alia Atlas]

Based upon the WGLC comments, I have updated these two drafts.  Because I
believe that the changes are not particularly controversial (except for the
new reference to NETCONF and RESTCONF), I've published the updated versions
so that the WG can verify the changes at the same time as my co-authors.

The differences for the architecture draft can be found at:
http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-architecture-03difftype=--htmlsubmit=Go%21url2=draft-ietf-i2rs-architecture-04

and for the problem-statement at:
http://www.ietf.org/rfcdiff?url1=draft-ietf-i2rs-problem-statement-03difftype=--htmlsubmit=Go%21url2=draft-ietf-i2rs-problem-statement-04

Thanks,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Working Group Last Call on architecture and problem statement drafts (redux)

[Alia Atlas]

Dean,

On Fri, Jun 6, 2014 at 9:57 AM, Dean Bogdanovic de...@juniper.net wrote:

 Jeff,

 Problem statement:  suggested changes, several times, still waiting for
 those to be addressed in the draft. As my comments are not addressed, I
 don't think draft is ready for WGLC or RFC.


Just a reminder - I have the changes ready to go as discussed.  We were
waiting on any other comments from the WGLC before updating the draft.
 Given the paucity of such comments and the
availability of integers, I'll just submit it.

Alia


 Architecture document: ready for WGLC, ready for RFC

 Dean

 On Jun 5, 2014, at 4:29 PM, Jeffrey Haas jh...@pfrc.org wrote:

  Working Group,
 
  The original deadline for comments on WGLC for the problem statement and
  architecture drafts of May 30 has passed with no comment whatsoever.
 
  While we all realize that there's a bit of exhaustion going on with
 regard
  to these drafts, they are a bit of process we simply must get done in
 order
  to fully move forward with our agenda of putting together data models.
 
  We are *NOT* going to hold that work up further - it is clear that there
 is
  consenus to start making that progress.
 
  To assist us with putting this work behind us, please respond to the
  following questions:
 
  http://datatracker.ietf.org/doc/draft-ietf-i2rs-problem-statement/
  Have you read the problem statement draft?
  Do you think it is ready to be published as a RFC?
  (If no, please respond to the list with issues.)
 
  http://datatracker.ietf.org/doc/draft-ietf-i2rs-architecture/
  Have you read the architecture draft?
  Do you think it is ready to be published as a RFC?
  (Ditto.)
 
  -- Jeff
 
  ___
  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

Re: [i2rs] draft-ietf-i2rs-problem-statement-01

[Alia Atlas]

Hi Dean,

Sorry for the long delay :-(  I got felled by an ear infection.
Responses in-line.

On Tue, May 6, 2014 at 7:05 PM, Dean Bogdanovic de...@juniper.net wrote:
 Alia, Tom, Dave,

 Have few comments on chapter 5 in the draft

 The following requirement is fine, but some consideration have to be put in.
 Example, creating a filter construct or routing table has to be finished,
 before the next operation like add term to the filter or add route to the
 routing table is possible.

 Multiple Simultaneous Asynchronous Operations:   A single application
   should be able to send multiple operations via I2RS without being
   required to wait for each to complete before sending the next.

 So would suggest changing from multiple operations to multiple independent
 operations

[Alia] Agreed and changed.

 High-throughput is always nice to have, but the quantification is a bit
 wishy washy.

[Alia] I know - it varies based on use-case and what's being controlled.

  High-Throughput:   At a minimum, the I2RS Agent and associated router
   should be able to handle a considerable number of operations per
   second above what basic Netconf or a propretiary CLI can.

 What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over
 NETCONF. Question: what is RPC doing? Is it simple operational get or large
 config push? Or some other complex RPC?
 There is also difference in creating logical interfaces and adding term to a
 filter or adding route to a routing table. Creating interface is most taxing
 one and adding term is fastest create operation. IMO, NETCONF has no problem
 with throughput, it is the instrumentation and that is something we should
 focus in I2RS.
 What constructs do we want to control via I2RS and depending on that, make
 sure that the protocol can sustain max throughput.

[Alia] I know it depends on the back-end as well as the protocol.  Remember this
is the problem-statement and these are desired aspects.  I've been
trying to encourage
less wishy-washy numbers for use-cases, but without much success.
Should I just claim
a goal of a sustained rate of 1 simple operations/sec?  OR bursts?

[Alia] I'll update it to:

At a minimum, the I2RS Agent
  and associated router should be able to handle a
  considerable number of operations per second (for example
  10,000 per second to handle many individual subscriber
  routes changing simultaneously).

I'd like better wording and example though.

 In the next chapter you are mentioning

 Responsive:   It should be possible to complete simple operations
   within a sub-second time-scale.


 Here you are stating simple operation, so why not define few simple
 operations and put some quantification with it (in the below examples I'm
 pulling the numbers out of my hat)

 example:

 read routes - single prefix per transaction  0.5sec
 - multiple prefixes per transaction  time on the wire + 0.5sec
 add route - single prefix per transaction  0.5 sec
 - multiple prefixes per transaction 1000 routes/sec

 get filter info - single filter per transaction  0.5sec
 - multiple filters and terms per transaction   time on the wire + 0.5sec
 create filter - single filter per transaction  0.5 sec
 - multiple filters per transaction  2000/sec
 add term to filter - single term per transaction  0.5sec
 - multiple terms per transaction  3000/sec

 get interface info  - single interface per transaction  0.5 sec
 - multiple interfaces per transaction  time on the wire + 0.5 sec
 create interface - single interface per transaction  0.5 sec
 - multiple interfaces per transaction 100/sec

[Alia] Hmm, I think this is too much detail for a problem-statement.  What about
for responsive:  Within a sub-second time-scale, it should be
possible to complete simple operations (e.g. reading or writing a
single prefix).

 I'm thinking how can you do assurance for i2rs. It looks as it is covered in
 following paragraph

   Scalable, Filterable Information Access:  To extract information in a
   scalable fashion that is more easily used by applications, the
   ability to specify filtering constructs in an operation requesting
   data or requesting an asynchronous notification is very valuable.


 but it is not spelled out.

[Alia] Can you clarify please?

 Dean




 ___
 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

Re: [i2rs] draft-ietf-i2rs-problem-statement-01

[Alia Atlas]

Jamal,

I'd like to get some good numbers for use-cases to put in.

For operations, it's not clear to me that they will always be batched
in bulk as much as
is done for down to the forwarding plane - I think aspiring to
100,000s ops/sec is a bit
unlikely unless it is carefully crafted with good bulk operations.
I'm putting in 10,000 as
being more than we can generally do now with NetConf or CLI - but I'd
be happy to see
a use-case that justifies more.

Alia

On Wed, May 7, 2014 at 9:13 AM, Jamal Hadi Salim h...@mojatatu.com wrote:
 On Tue, May 6, 2014 at 7:05 PM, Dean Bogdanovic de...@juniper.net wrote:

 High-throughput is always nice to have,

 Is it nice to have or must have?

but the quantification is a bit wishy washy.


 Agreed.

  High-Throughput:   At a minimum, the I2RS Agent and associated router
   should be able to handle a considerable number of operations per
   second above what basic Netconf or a propretiary CLI can.

 What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over
 NETCONF. Question: what is RPC doing? Is it simple operational get or large
 config push?
 Or some other complex RPC?
 There is also difference in creating logical interfaces and adding term to a
 filter or adding route to a routing table. Creating interface is most taxing
 one and adding term is fastest create operation.
IMO, NETCONF has no problem
 with throughput, it is the instrumentation and that is something we should
 focus in I2RS.
 What constructs do we want to control via I2RS and depending on that, make
 sure that the protocol can sustain max throughput.


 We need to pick something as a metric since as you say it will depend on the
 object type. The RIB table sounds like a reasonable object to standardize on.
 Pick a number like 1M table entries (large enough so as to be measurable).

 Throughput:
 This refers to some bulk table create/updates/dumps. Very few transactions/sec
 are needed, essentially in this case the agent and client are engaged
 in batching the entries
 they send to the other party.
 To handwave some numbers performance numbers:
 I am going to pick say 10s to 100s of thousands rows per/sec.
 We need bidirectional numbers.

 Transactions rate:
 This is a measure of request/response. Again using the RIB example -
 this would mean taking
 each of the 1M rows and send them one at a time (i.e window of 1). Eg
 a request from the
 client to create/update is sent to the agent and when a success
 response is received by the
 client the next request is issued . until all of 1M transactions
 are complete

 In the next chapter you are mentioning

 Responsive:   It should be possible to complete simple operations
   within a sub-second time-scale.


 Here you are stating simple operation, so why not define few simple
 operations and put some quantification with it (in the below examples I'm
 pulling the numbers out of my hat)

 example:

 read routes - single prefix per transaction  0.5sec
 - multiple prefixes per transaction  time on the wire + 0.5sec
 add route - single prefix per transaction  0.5 sec
 - multiple prefixes per transaction 1000 routes/sec

 get filter info - single filter per transaction  0.5sec
 - multiple filters and terms per transaction   time on the wire + 0.5sec
 create filter - single filter per transaction  0.5 sec
 - multiple filters per transaction  2000/sec
 add term to filter - single term per transaction  0.5sec
 - multiple terms per transaction  3000/sec

 get interface info  - single interface per transaction  0.5 sec
 - multiple interfaces per transaction  time on the wire + 0.5 sec
 create interface - single interface per transaction  0.5 sec
 - multiple interfaces per transaction 100/sec


 We need to have some quantification numbers. They dont have to be precise
 but could be in the ranges. I think what you describe above matches my 
 thinking.
 Your multiple per transaction is essentially a batching artifact
 which falls under
 throughput metric. The  single per transaction is a transaction metric.

 Having said that: I know you gave those numbers as examples, but they
 are way too low ;-

 I'm thinking how can you do assurance for i2rs. It looks as it is covered in
 following paragraph

   Scalable, Filterable Information Access:  To extract information in a
   scalable fashion that is more easily used by applications, the
   ability to specify filtering constructs in an operation requesting
   data or requesting an asynchronous notification is very valuable.


 but it is not spelled out.


 I would consider the throughput, transaction rate and latency in that
 category as
 well.

 cheers,
 jamal

 ___
 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

Re: [i2rs] Interface to The Internet Routing System (IRS)

[Alia Atlas]

Hi Fabio,

Take a read through the architecture
(http://tools.ietf.org/html/draft-ietf-i2rs-architecture) and
problem-statement
(http://tools.ietf.org/html/draft-ietf-i2rs-problem-statement).

If you can provide your questions and review after that, it would be
quite helpful to know how solid a job the drafts do of explaining the
work.

Regards,
Alia

On Wed, May 7, 2014 at 7:27 AM, FABIO ZACCANTTE zaccan...@gmail.com wrote:
 I am starting in the I2RS and my question is where stay I2RS, in the router
 or controller.

 Someone has picture that represents the controller, the router, the network
 and I2RS

 Regards,
 Fabio.

 ___
 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

Re: [i2rs] draft-ietf-i2rs-problem-statement-01

[Alia Atlas]

Dean,

Thanks for the thorough review!  I'm traveling so will take until Friday for a 
full response.

Alia



 Original message 
From: Dean Bogdanovic de...@juniper.net
Date: 05/06/2014 6:05 PM (GMT-06:00)
To: Alia Atlas akat...@juniper.net,Thomas Nadeau 
tnad...@lucidvision.com,wa...@cisco.com
Cc: i2rs@ietf.org i2rs@ietf.org
Subject: draft-ietf-i2rs-problem-statement-01


Alia, Tom, Dave,

Have few comments on chapter 5 in the draft

The following requirement is fine, but some consideration have to be put in. 
Example, creating a filter construct or routing table has to be finished, 
before the next operation like add term to the filter or add route to the 
routing table is possible.

Multiple Simultaneous Asynchronous Operations:   A single application
  should be able to send multiple operations via I2RS without being
  required to wait for each to complete before sending the next.

So would suggest changing from multiple operations to multiple independent 
operations

High-throughput is always nice to have, but the quantification is a bit wishy 
washy.

 High-Throughput:   At a minimum, the I2RS Agent and associated router
  should be able to handle a considerable number of operations per
  second above what basic Netconf or a propretiary CLI can.

What does mean basic NETCONF? Today I can do couple hundred RPCs/sec over 
NETCONF. Question: what is RPC doing? Is it simple operational get or large 
config push? Or some other complex RPC?
There is also difference in creating logical interfaces and adding term to a 
filter or adding route to a routing table. Creating interface is most taxing 
one and adding term is fastest create operation. IMO, NETCONF has no problem 
with throughput, it is the instrumentation and that is something we should 
focus in I2RS.
What constructs do we want to control via I2RS and depending on that, make sure 
that the protocol can sustain max throughput.

In the next chapter you are mentioning

Responsive:   It should be possible to complete simple operations
  within a sub-second time-scale.

Here you are stating simple operation, so why not define few simple operations 
and put some quantification with it (in the below examples I'm pulling the 
numbers out of my hat)

example:

read routes - single prefix per transaction  0.5sec
- multiple prefixes per transaction  time on the wire + 0.5sec
add route - single prefix per transaction  0.5 sec
- multiple prefixes per transaction 1000 routes/sec

get filter info - single filter per transaction  0.5sec
- multiple filters and terms per transaction   time on the wire + 0.5sec
create filter - single filter per transaction  0.5 sec
- multiple filters per transaction  2000/sec
add term to filter - single term per transaction  0.5sec
- multiple terms per transaction  3000/sec

get interface info  - single interface per transaction  0.5 sec
- multiple interfaces per transaction  time on the wire + 0.5 sec
create interface - single interface per transaction  0.5 sec
- multiple interfaces per transaction 100/sec

I'm thinking how can you do assurance for i2rs. It looks as it is covered in 
following paragraph


  Scalable, Filterable Information Access:  To extract information in a
  scalable fashion that is more easily used by applications, the
  ability to specify filtering constructs in an operation requesting
  data or requesting an asynchronous notification is very valuable.

but it is not spelled out.

Dean



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

[i2rs] Planned Discussions: Data Model Language and Protocol

[Alia Atlas]

This IETF meeting we are planning to have discussions about what the
alternatives are for data modeling languages and protocols are.

So far, we have volunteers to discuss YANG, RestConf, and ForCES.

If you have interest in discussing any other options, please speak up now.

Please, if you can, discussion on the list beforehand would be useful as
well.

We have to turn I2RS from a concept into something that we can implement and
have interoperable - which means picking both a data-model language and
protocol to
base our work and changes on very very soon.

Thanks,
Alia (wg-chair hat on)
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] draft-ietf-i2rs-architecture-02 mutual authentication

[Alia Atlas]

John,

Thanks for the review and comment.  I absolutely agree.
Joel mentioned that we'd missed the agent authentication requirement.
It will have to be in the next version.

Any other feedback or suggestions?

Alia


On Thu, Feb 20, 2014 at 8:00 AM, John Mattsson
john.matts...@ericsson.comwrote:

 Hi,

 Reading draft-ietf-i2rs-architecture-02 I notice that the draft only talks
 about ³client authentication² with the possible exception of:

 ³all control exchanges between the I2RS client and agent should be
 authenticated and integrity protected² (Which could indicate that messages
 from the agent is authenticated and not only integrity protected.)

 My view is that the client and the agent should always be mutually
 authenticated. Otherwise I2RS is open for attacks with fake agents falsly
 claiming to be a Routing Element.

 E.g. the current draft of ETSI Network Functions Virtualisation (NFV);
 NFV Security; Problem Statement states that:

 It is important, of course, for there to be two-way authentication
 between the controller and switching/routing entities. Should the
 controller be spoofed, the switching fabric is at risk of being taken over
 and misused. On the other hand, should the switches be spoofed, there are
 equally concerning issues:

 The intended topology of the virtual network may be revealed to an attack,
 yielding useful mapping and attack data;

 The controller, which should act as a trusted holder of knowledge of the
 state of the network, ceases to hold this role.
 

 In any case, text talking about the requirements on agent authentication
 should be added to the architecture draft.



 - Small editorial in section 4:
 requires integrity, privacy and replay protection. - requires
 integrity, confidentiality and replay protection.


 ---
 -
 JOHN MATTSSON
 MSc Engineering Physics, MSc Business Administration and Economics
 Ericsson IEFT Security Coordinator
 Senior Researcher, Security

 Ericsson AB
 Security Research
 Färögatan 6
 SE-164 80 Stockholm, Sweden
 Phone +46 10 71 43 501
 SMS/MMS +46 76 11 53 501
 john.matts...@ericsson.com

 ___
 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] use-cases - discussion please

[Alia Atlas]

If you were to look at our charter, unsurprisingly we have use-cases to be
completed before information models.  I would strongly encourage discussion
of the use-case drafts and serious work on turning them into something that
the working group could accept.

I've certainly heard the concerns that we haven't picked a data-modeling
language or protocol yet - and that I2RS may be going too slowly for
various open-source projects.

The speed the working group goes is up to each of you!   We can't really
ask for a recharter to include data models or anything else until we get
the basics off our plate.

Just a reminder of our original Goals and Milestones below:

Goals and Milestones:
  Jul 2013 - Request publication of an Informational document defining the
problem statement
  Jul 2013 - Request publication of an Informational document defining the
high-level architecture
  Aug 2013 - Request publication of Informational documents describing use
cases
  Sep 2013 - Request publication of an Informational document defining the
protocol requirements
  Sep 2013 - Request publication of an Informational document defining
encoding language requirements
  Feb 2014 - Request publication of Standards Track documents specifying
information models
  Feb 2014 - Request publication of an Informational document providing an
analysis of existing IETF and other protocols and encoding languages
against the requirements
  Feb 2014 - Consider re-chartering

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] TED extension in topology info model

[Alia Atlas]

Of course!  Glad and eager to have you join the conversation here.

Alia
On Jan 9, 2014 7:29 AM, Vijay K. Gurbani v...@bell-labs.com wrote:

 On 01/09/2014 09:23 AM, Alia Atlas wrote:

 Vijay,

 No , that is completely inaccurate.  The topology export is specifically
 in charter for I2RS.

 Can you please explain the critical overlap you see with alto such that
 you are trying to kill discussion on the I2RS making list?


 Alia: Argh, I am sorry.  I mistook i2rs for i2aex mailing list!  The
 i2aex was a BoF we did in the Paris IETF and in my email deluge this
 morning, I conflated i2rs with i2aex.  It is the i2aex list that is
 inert, having served its purpose.

 Sorry for the interruption.  Please continue discussion as intended,
 as I was not trying to kill any discussion on the i2rs mailing list.

 I will make sure I get my first cup of coffee before responding :-)

 Cheers, and again, much apologies.

 - vijay
 --
 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
 Email: vkg@{bell-labs.com,acm.org} / vijay.gurb...@alcatel-lucent.com
 Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

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

Re: [i2rs] topology info model - what makes it a network model vs. a device model

[Alia Atlas]

Sorry for the late response, but to summarize...

What I am hearing is several things:

a)  We definitely need a device's perspective of topology - to include at
least the IGP's LSDB and probably local interfaces.
b)  There is a strong desire for a network-wide topology-model - even
though any protocol (north-bound, etc) to use that is definitely NOT in
scope for I2RS.   A key additional complexity for this is correlating the
data from multiple devices' perspectives - and to get this right we should
do both the device's perspective and the network-wide perspective in
combination.  However, it is not clear that any complex correlation logic
would be in scope.
c) As per the charter, writing topology is out of scope.
d) Filtering of topology information by the I2RS agent for extraction would
be very useful.
e) Topology information is only PART of the IGP IM (whether we have an OSPF
IM and an ISIS IM or...)

I think that part of what we are running into is the need for indirection
between different IMs - so that an IGP IM can express its LSDB based from a
generic links-and-nodes model - but that may still have more information
than a network-centric model would keep.

It would also be useful to discuss what else should be in the IGP IM...

While we've had a good discussion, is anyone (other than Jan, Alex, etc on
(b)) specifically planning on working on any of the topology related IMs as
I described above?

In reference to my earlier comment about I'm also not comfortable on
having only one IM for basing all our requirements off of., what I meant
is that I2RS is rapidly progressing towards gap-analysis for both
data-modeling languages and protocols  (I'd love to see drafts soon) - and
the reasoning for the requirements come from the architecture (fairly
baked), the RIB IM (in good shape), various suggested use-cases (need work)
and possibly Jan's network-centric topology IM (under serious discussion).
  I realize that
draft-rfernando-i2rs-protocol-requirementshttp://trac.tools.ietf.org/id/draft-rfernando-i2rs-protocol-requirements-00.txt-00
and 
draft-swhyte-i2rs-data-collection-systemhttp://trac.tools.ietf.org/id/draft-swhyte-i2rs-data-collection-system-00.txt-00
also give some requirements and guidance - but they are also not yet WG
drafts.

We do need to get moving :-)

Alia



On Tue, Nov 12, 2013 at 1:56 PM, Edward Crabbe e...@google.com wrote:

 With my chair hat off:

 Any 'device-centric' model must be composable into a 'network-wide'
 model, otherwise it's not particularly useful.
 So yes, +1 and agree with Shane.

 with my chair hat on:

 I believe *this specifically* is in charter.


 On Thu, Nov 7, 2013 at 11:12 AM, Shane Amante sh...@castlepoint.net
 wrote:
 
  On Nov 7, 2013, at 9:15 AM, Nikolay Milovanov n.milova...@gmail.com
 wrote:
 
  In the end to build a network centric info/data model out of this the
  network topology manager will have to collect and transform information
  gained from many network devices.
 
 
  +1.
 
  I believe I may be observing a tension between the traditional IETF view
 of
  how do I make two devices communicate together, i.e.: what's the
 protocol
  that allows that communication to occur robustly, vs. an operator view of
  Sure, I need protocols to make two devices talk to each other, but
 what's
  more critical for my business is to look at the whole network, which is a
  collection of devices.  A Network Topology Information Model would
 assist
  operators with having a cohesive view of the overall network as a
 system,
  because that's the foundation upon which _services_ are delivered ...
 both
  within the data-path between various NE's and on top of various NE's.
 
  So, +1 to network-centric topology IM model.
 
  -shane
 
 
 
  ___
  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

Re: [i2rs] topology info model - what makes it a network model vs. a device model

[Alia Atlas]

Hi Sri,

Sorry for top-posting.   I generally agree that understanding what
information should be including in the device perspective's topology IM in
order to resolve discrepancies is important.  I don't think that we need
to recreate IGPs' mechanisms for this - but rather include the information
in there so that resolution can be done.  For instance, with an LSA - it is
clear which is more recent.  If multiple router LSAs from the same router
are reported by different devices, then clearly the network is reconverging
- and there can be flags indicating this along with old state and new
state.  Ideally, one could associate the time that a device originated an
LSA (if that device is contributing information) as well.   For each OSPF
area, it could be marked as reconverging or stable.  I think that probably
one would have two topologies available - the old and the new where the
default would be to work with the new.

Does that make sense to you?

Alia


On Thu, Nov 7, 2013 at 4:56 PM, Sriganesh Kini
sriganesh.k...@ericsson.comwrote:

 Hi Nikolay,

 On Thu, Nov 7, 2013 at 1:33 PM, Nikolay Milovanov n.milova...@gmail.com
 wrote:
  Hi Sri,
 
  I guess instead of complete model of entire network topology  it
 should be a model of the network topology as visible from a particular
 device perspective.

 This is still a device-centric topology view. Even though it may be of
 the whole network and not just its immediate neighbors, it is still a
 device-centric view. Unless the device itself has a strong-consistency
 model of the entire network, in which case I would like to know what
 that is.

  The  topology discoverer acting as an i2rs client will have to have some
 rules in order to handle differences between network models received by
 different devices.

 My question to the group is whether those rules are in the I2RS
 charter. Will we be designing those procedures and mechanisms in I2RS
 WG (this may be replicating a link-state IGP's db update procedures).

 
  It is interesting how the i2rs client will do the merge if some edges
 part of the model received from one network node(agent) and are missing
 from the model received by its neighbor? Shall does go into the entire
 network model or not? I guess this is an implementation detail not really
 related to the info model spec. For example in such cases there might be a
 discrepancy mechanism able to handle that. It might be configurable and
 able to do different things as per the exact network use case.
 

 I don't think this is an implementation detail. A network-centric
 topology model must be recursively stackable. It must be standardized
 as to how the discrepancies are handled.

  I have a question to the group members related to  How formal that model
 will has to be?. For example it might contain not only nodes and edges but
 also some of their key properties. It might be useful if for example some
 of the edge properties to be the local/remote interface through which the
 edge has been built also the local/remote L2/L3 network address used for
 edge building.
  Also is interesting how to ensure that the data coming from different
 nodes in the network but related to the same node/edge will have the same
 unique ID so that the network topology manager will be able to merge it
 correctly.

 Seems like we are getting into a link-state advertisement discussion here
 :-)

 
  Nikolay
 

 - Sri

 
  On Nov 7, 2013, at 11:11 PM, Sriganesh Kini wrote:
 
  A critical question is whether the merging of the models from each
  device is within the scope of I2RS. Also note that complete model of
  entire network topology can be misleading. This may be true for small
  networks within a single administrative domain, but as the scope of
  the network increases (e.g. multiple administrative domains) there
  will not be a single way to get the entire network topology, but
  there will be some details that will be abstracted out.
 
  - Sri
 
  On Wed, Nov 6, 2013 at 11:17 PM, Nikolay Milovanov
  n.milova...@gmail.com wrote:
  Most likely the network-centric topology models coming from each of the
  devices will have to be merged by the network topology manager in
 order the
  rest of the applications to be able to benefit from a complete model
 of the
  entire network topology.
 
  ___
  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

Re: [i2rs] topology info model - what makes it a network model vs. a device model

[Alia Atlas]

Hi Jan,

Sorry for being so long in replying - but to answer your questions
finally...

On Thu, Nov 7, 2013 at 3:04 AM, Jan Medved (jmedved) jmed...@cisco.comwrote:

  Hi Alia,

  Thanks for starting the conversation :-)

  IMO, the lines between 'network-centric' and 'device-centric' are a
 little blurred. For the sake of argument, let me agree with Joel that the
 I2RS WG's scope should be limited to a single routing system. Let me ask a
 few questions then:

- Is an OSPF router or an IS-IS router a 'routing system', as defined
in the WG charter? If yes, would its LSDB be considered 'topology
information' as defined in the WG charter?  And if the the answer to the
latter question is yes, would reading the LSDB information from the router
via a tbd. I2RS protocol be considered 'extraction of information
about topology from the network', as defined in the WG charter?

 Yes - absolutely - but the LSDP is not the only information that needs to
be in an OSPF/ISIS IM.


- Is a BGP Router Reflector a routing system, as defined in the WG
charter of the WG? If yes, would the LSDB information (potentially
collected from multiple IGP areas) in RR's BGP-RIB be considered 'topology
information' as defined in the WG charter? And if the the answer to
the latter question is yes, would reading the LSDB information from the RR
be considered 'extraction of information about topology from the
network', as defined in the WG charter? And if the BGP RR implements
BGP-LS, would extracting the LSDB information from the RR be in scope of
the WG? Could BGP-LS actually be considered a candidate for an I2RS
protocol  that would  be 'extracting information about topology from
the network'?

 Reading the topology info collected by BGP-LS would qualify.   I am torn
about having BGP-LS being considered an I2RS protocol.  We certainly
started I2RS with the idea of being inclusive of multiple protocols that
could provide the desired functionality.  Since then, I think that the WG
has been more focused on a single protocol - though with the potential for
off-loading, such as requesting information but having it delivered via
IPFIX or possibly a log-file via SCP.  BGP-LS, of course, has some of the
desired performance characteristics, but certainly isn't quite a data-model
driven protocol.

What I'd like to see in this space would be an IM for BGP-LS with a mapping
to the data in BGP-LS.  Then, one could either use I2RS to request the data
and information stream or one could simply implement BGP-LS and listen.  I
say simply but I've been given to understand that implementing BGP, even
as just a listener, is adding a non-trivial burden for network
applications.  Of course, how relevant that is for just getting something
going or for a model with an I2RS broker is another question.

Regards,
Alia


  Thanks,
 Jan


   From: Alia Atlas akat...@gmail.com
 Date: Wednesday, November 6, 2013 6:23 PM
 To: i2rs@ietf.org i2rs@ietf.org

 Subject: [i2rs] topology info model - what makes it a network model vs.
 a device model

   I'd really like to start a conversation about the differences between a
 topology IM model that is network-centric vs. device-centric.  Clearly the
 WG has strong and different opinions about it.

  Since many people are here in Vancouver, focused on IETF and not their
 day-jobs, this seems like a good time to get it rolling...

  Alia


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

[i2rs] topology info model - what makes it a network model vs. a device model

[Alia Atlas]

I'd really like to start a conversation about the differences between a
topology IM model that is network-centric vs. device-centric.  Clearly the
WG has strong and different opinions about it.

Since many people are here in Vancouver, focused on IETF and not their
day-jobs, this seems like a good time to get it rolling...

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

[i2rs] Please send in your slides

[Alia Atlas]

For those of you who have not yet sent in your slides for today's meeting,
please do so ASAP.

Thanks,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Architecture Discussion 5: Client Redundancy

[Alia Atlas]

Hi Kwang-koog,

I apologize for the long delay in responding.


On Fri, Oct 4, 2013 at 5:14 AM, KwangKoog Lee kwangkoog...@gmail.comwrote:

 Hi Alia. This is Kwang-koog from KT.

 I checked many opinions from i2rs experts about the client redundancy.
 Thanks for very meaningful discussion to more advance i2rs.

 From service provider perspective, active/standby operation of network
 elements through dualization is mandatory for reliable operation from any
 failure. So, I am welcoming for the addition of the client redundancy part.
 Thank you.

 Regarding to this, I ask you something for clarifying the understanding of
 the i2rs architecture :-)

 As seen in Figure 1 of the architure document, a network application has
 to have a client? Or multiple network applications can attach to a single
 client. Referring to Sec. 4, an I2RS client can interact with multiple
 network applications. The next question is that network applications and
 client can be physically separated?


Yes, the architecture supports both models.  Either the network application
has the I2RS client as part of itself (basically a library or the like) or
the network application could talk via some protocol  to an I2RS client.


  Additionally, in Sec. 6.5 Connectivity, you state that There are three
 different assumptions that can apply to handling dead clients. The first is
 that the network applicaions or management systems will detect a dead
 network application and iether restart that network application .
 Network applications can check the status of other network applications
 each other? What is the management system? The first sentence is saying the
 handling of dead clients, but the second sentence says the dead network
 application. I want to cleary understand those matters.


The idea here is that there is some monitoring capability to determine that
a application has failed - that could be the network application with an
I2RS client, a network application without an I2RS client, or the
standalone I2RS client.  This could probably use some clean-up in the text.


   Those might be simple questions for you. If so, appologize my lack of
 comprehension :p


Not at all!  This is how we get a better and clearer draft.

Thanks,
Alia


 Thank you in advance and I also appreciate your efforts for i2rs.
 Bye.

 best regards,
 Kwang-koog Lee


 On Thu, Sep 12, 2013 at 11:59 PM, Alia Atlas akat...@gmail.com wrote:

 In draft-ietf-i2rs-architecture-00 Sec 6.4.1:

 I2RS must support client redundancy. At the simplest, this can be

handled by having a primary and a backup network application that
both use the same client identity and can successfully authenticate
as such.  Since I2RS does not require a continuous transport
connection and supports multiple transport sessions, this can provide
some basic redundancy.  However, it does not address concerns for

troubleshooting and accountability about knowing which network
application is actually active.  At a minimum, basic transport
information about each connection and time can be logged with the
identity.  Further discussion is necessary to determine whether
additional client identification information is necessary.[[Editor's
note: This requires more discussion in the working group.]]


 I would like to start this discussion.  During and after the Berlin IETF, 
 there

 was significant discussion on the list.  I tried to capture the ideas that 
 were

 expressed then.  Is what is in the draft now sufficient?  How should it be 
 improved

 upon?


 Thanks,

 Alia (WG-Chair hat off)


 ___
 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

Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-00

[Alia Atlas]

I was looking for a reasonable base set to put in there.

Alia


On Fri, Oct 11, 2013 at 3:08 PM, Edward Crabbe e...@google.com wrote:

 Couldn't agree more ^_^

 On Fri, Oct 11, 2013 at 9:01 AM, Russ White ru...@riw.us wrote:
 
  I think a variety of filtering is possible. I can start creating an
  exhaustive
  list.but need more input from WG (esp from those who intend on using the
  RIB model from a RIB client) on what would be useful to them. Here are a
  few possibilities.
 
  Rather than trying to come up with every possible filter, though, why
 don't
  we build an extensible infrastructure, and let use cases drive the
 filters
  actually specified? We would need a base set, but making an exhaustive
 list
  would, IMHO, be, well, err... exhausting.
 
  :-)
 
  Russ
 
 
  ___
  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

Re: [i2rs] comments on draft-ietf-i2rs-rib-info-model-00

[Alia Atlas]

Sorry - to be even clearer, I think that the list that Nitin and Joe
suggested is a great start and sufficient until and unless we hear
use-cases where that isn't so.

I'd like to amplify on what Tag is meant - since I don't, off-hand,
recall seeing it in the RIB Info model...

Alia


On Fri, Oct 11, 2013 at 12:12 PM, Joe Marcus Clarke jcla...@cisco.comwrote:

 On 10/10/13 2:46 PM, Nitin Bahadur wrote:

 Hi Alia,

   I'd love to see a bit more detail fleshing out the
 events/notification section and some thought given to what different
 mechanisms make sense for the information collection stream.  For
 instance, what types of filtering or thresholding can be done by a
 client who wants to learn the RIB information.

 I think a variety of filtering is possible. I can start creating an
 exhaustive list…but need more input from WG (esp from those who intend
 on using the RIB model from a RIB client) on what would be useful to
 them. Here are a few possibilities.

   * Filter routes adds/deletes/updates based on:
   o Route address family
   o Route prefix (for IP)
   o Unicast vs Multicast (IP)
   * Filter lists of type allow and exclude


 Thresholding is tricky, esp if the rib agent has to implement it. If
 someone wants to slow down the number of updates sent/recd per sec, the
 simplest way would be to set a small socket-buffer size on the TCP
 connection….
 Adding logic in the rib agent to send only N updates per M seconds would
 complicate things.

  For the reading or notifications - is it possible to learn which
 protocol has installed a particular route?

   What types of filters beyond routing instance, RIB, and match can be
 used for reading routes?

 Yes…there can be filter on protocol-type (yet to be defined). So you
 could filter routes on installed only by ISIS.
 Learning who has installed a route in a particular RIB should be doable
 as well.


 I think this is a good base set of filter criteria.  I would also add VRF
 (or maybe VRF is assumed based on the RIB instance delivering the event).
  To summarize:

 * Address family
 * Prefix/prefix len
 * Unicast/multicast
 * Protocol
 * VRF

 And filter based on add/remove/update and include/exclude.  Should we
 discuss what kind of route attributes an event would carry to the consumer?
  At a minimum, I think events should contain everything above (including
 event type) as well as:

 * Next hop interface
 * Next hop gateway
 * Time of route add/remove/update
 * Metric
 * Tag

 And to Russ' point, make things extensible for adding custom, per-vendor
 or per-protocol attributes as well.

 Joe


  Nit:  The multicast match is missing from the match in the BNF and
 from Figure 2.  (Some of the later figures aren't labeled either).


 Fixed.

 Thanks
 Nitin


 __**_
 i2rs mailing list
 i2rs@ietf.org
 https://www.ietf.org/mailman/**listinfo/i2rshttps://www.ietf.org/mailman/listinfo/i2rs



 --
 Joe Marcus Clarke, CCIE #5384, |  |
 SCJP, SCSA, SCNA, SCSECA, VCP|  |
 Distinguished Services Engineer ..:|::|:..
 Phone: +1 (919) 392-2867 c i s c o  S y s t e m s
 Email: jcla...@cisco.com

 --**--**
 

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

[i2rs] Please send agenda items and requests to Ed and I

[Alia Atlas]

I2RS will be meeting on Tuesday Nov 5 from 16:10 to 18:40.

Please send both Ed and I any agenda items and requests.
Drafts should, of course, be published in advanced and strongly
preferably be discussed on the mailing list.

Regards,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs

Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. permanent)

[Alia Atlas]

Hi Joe,

Summarizing up top (but leaving context)

For a graceful Agent restart (i.e. not a crash), I think the behavior can
be implementation-dependent.  The implementation can either notify all
Clients that have data written that the state is being preempted/torn down
or it can just notify all Clients (that it knows of) that the Agent is
going down.  These are important notifications to capture in the I2RS Agent
Info-Model.  I don't think that either needs to be explicitly required as
the only mode.  I am certainly willing to be convinced otherwise.

For the case of an Agent crashing, I'm quite reluctant to create a
heartbeat or persistent connection.   This is a lot of complexity to add
for what should be a quite rare case.  If the Agent crashes, leave the
state and the Client will get an error when it tries to connect or
otherwise request something.  This does argue that on connection, the
Client should get an indication of something like an Agent boot count
/session id (and boot time).   Russ's idea of storing known clients for the
agent to connect to on reboot makes sense to me.

I really dislike the idea of adding significant complexity to handle an
edge failure case.

Alia


On Fri, Sep 13, 2013 at 12:58 AM, Joe Marcus Clarke jcla...@cisco.comwrote:

 On 9/12/13 3:49 PM, Alia Atlas wrote:
  [Alia] But we (the WG) said that it was an error because we expect
  coordination
  between the applications to avoid multiple writers of the same data.
   It's not an
  error because the Agent says so - the Agent would just report back what
  happened
  (successful write or fail due to higher priority).

 My point was that the Agent knows the priority.  This isn't passed to
 the RS.

  [Alia] As Joel had said, I think we're trying to avoid the need for
  persistent
  connections just to confirm liveness.  It's a heavy-handed way to do it.
   That said,
  we could use a mechanism to determine if the RS is up and if the
 associated
  Agent is up.  Of course, there can be multiple Agents per RS - each
  supporting
  different services or such. For a router reboot, a Client that is
  learning topology
  would hear very quickly that a router has failed or appeared.
 
  [Alia] So - developing a liveness detection mechanism is useful.  But
  what would
  be useful is the ability for the RS to notify interested clients on a
  failure.  Otherwise,
  what frequency would suffice for checking - when traffic can be being
  actively dropped
  or misrouted if the Agent has failed.Also - are we designing for the
  error-case of
  a crashed Agent rather than the normal case of a gracefully shut down
 Agent?

 I was raising the point of both.  In the graceful case, the Agent clears
 all state and notifies all Clients.  But the crash is a possibility, and
 we should stipulate what should happen to state.

 I don't think we want the RS doing anything to the Clients directly.  I
 think perhaps an Agent-Client heartbeat is a useful thing if the Client
 asks to be notified about changes.

 
  A third model I thought of was a broker model in which the Agent
  rebooting would be a broadcast event to all subscribers.
 
 
  [Alia] I've been assuming, I guess, that Clients would hear about router
  failures via
  the topology DM based from the IGP.

 Router failure of Agent failure?

 
 
  In either case, I saw that the Client would have some means of
 knowing
  the Agent went away.
 
 
  [Alia] I can see that if the Client knew that the Agent went away
  (ungracefully), that
  having the associated RS clean up state would be fine.  I haven't yet
  heard a fully baked
  design where the client would know rapidly.  We (you?) could come up
  with one, but
  that needs to be written down and agreed to.  Without that, I hear that
  the Client's state
  might suddenly disappear without the Client being able to tell - and am
  much more comfortable
  leaving it there to be removed either via CLI or to be read and then
  written again by the Client
  when it reconnects.

 I've been kicking around the idea of a pub-sub heartbeat.  This would
 give the Client awareness of the Agent's thereness.  If the heartbeat
 carried a boot count, the Client might not need for multiple dropped
 heartbeats before reapplying state.  I don't know if this is an ideal
 way to confirm liveness of the agent, though I'm happy to propose it
 more formally.  I think the exact approach would depend on what the
 pub-sub mechanism is determined to be.

  One other thing I haven't raised is the operator impact.  How else
 could
  an operator (i.e., owner/admin of a device) flush the I2RS changes?
  There might be a malicious change or just some bad state, and they
 want
  to clear that up.  A restart of the Agent could do it without
 reloading
  the device.
 
 
  [Alia]  Why wouldn't using the CLI to flush the I2RS changes work?

 It would.  I didn't realize you were okay with a graceful restart of the
 Agent purging all RS state

Re: [i2rs] Architecture Discussion 4: templates for Policy and QoS mechanisms

[Alia Atlas]

Sri,

I'm delighted to hear that some thought and progress is going on in this
area.
I agree that we'll want to have some templates (named objects) available.
 I don't see
trying to standardize all of these mechanisms - though a core set of types
(policing, rate-limiting, queuing, etc) certainly make sense.

I can see having a template with a type and name - and the application has
to understand what it was set up for.  One could add to that by specifying
a data-model that is used for that template...  Possibly we can agree on
some basic parameters that are generally supported or accepted as modeling
common behavior - and that can be pointed to (or to a proprietary
data-model that is more specific).

Alia


On Fri, Sep 13, 2013 at 12:41 AM, Sriganesh Kini 
sriganesh.k...@ericsson.com wrote:

 Hi Alia,

 As part of of evolving the RIB IM the authors are looking into
 routing-policies and policy-based-routing (PBR) IMs. As part of the PBR IMs
 we are discussing whether the QoS IMs (policing, rate-limiting, queueing
 ... etc) should be in scope and what they should include. As you quoted
 from the arch doc, these could vary widely across implementations and we
 are discussing what the core set may be. We have not finalized this yet and
 it is possible that the QoS IM would be in a separate draft.

 Also, as part of discussing routing-policies we have considered making
 templates (named objects) that can be re-used (e.g. across various RIBs).
 These objects should be at the top-level of the IMs. It would be useful to
 do this in a manner that is consistent across various IMs.

 Thanks
 - Sri


 On Thu, Sep 12, 2013 at 7:55 AM, Alia Atlas akat...@gmail.com wrote:

 In draft-ietf-i2rs-architecture-00 Sec 5.4.4:

  Many network elements have separate policy and QoS mechanisms,

including knobs which affect local path computation and queue control
capabilities.  These capabilities vary widely across implementations,
and I2RS cannot model the full range of information collection or
manipulation of these attributes.  A core set does need to be
included in the I2RS data models and in the expected interfaces
between the I2RS Agent and the network element, in order to provide
basic capabilities and the hooks for future extensibility.
[[Editor's note: This requires more discussion in the working
group.]]


 I would like to start that discussion now.


 Personally, I have not seen or heard much discussion or any 
 information-models

 around these templates.  What do people think is necessary?  How should this

 part of the architecture draft change?


 Thanks,

 Alia (WG-Chair hat off)






 ___
 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

Re: [i2rs] Architecture Discussion 3: Operations are Immediate and continuing

[Alia Atlas]

Oh, I totally agree as far as trying to have a minimal amount of state and
complexity.
My concern has been making the network from the client to the agent mission
critical,
but that's clearly documented in the architecture.  I just want to confirm
the consensus so
we can honestly remove the Editor's note and go forward.

Alia


On Fri, Sep 13, 2013 at 10:56 AM, Russ White ru...@riw.us wrote:


 Personally, I have heard that this is a good simplification.  Removing the

 ability to specify the start-time and end-time of an operation adds complexity

 and we don't clearly have use-cases that need it.  Does anyone have a 
 different

 perspective?


 I think the simplifying assumption here is that the controller should hold
 the time state, not the agent. In other words, rather than telling the
 agent to start action x at time y, the controller should just wait until
 time y, and then send start action x.

 The agent should designed with the minimal amount of state and complexity,
 to get adoption rates up, etc.

 :-)

 Russ


 
 ru...@riw.us
 ?@?.com (engineer without a portfolio)

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

Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. permanent)

[Alia Atlas]

On Thu, Sep 12, 2013 at 11:22 AM, Joe Marcus Clarke jcla...@cisco.comwrote:

 On 9/12/13 11:11 AM, Alia Atlas wrote:
  Hi Joe,
 
  On Thu, Sep 12, 2013 at 11:02 AM, Joe Marcus Clarke jcla...@cisco.com
  mailto:jcla...@cisco.com wrote:
 
  On 9/12/13 10:47 AM, Alia Atlas wrote:
   In draft-ietf-i2rs-architecture-00 Sec 5.2, it says:
  
   The I2RS Agent will not attempt to retain or reapply state across
  
  routing element reboot.  Determination of whether state still
  applies
  depends heavily on the causes of reboots, and reapplication is
 at
  least as likely to cause problems as it is to provide for
 correct
  operation.  [[Editor's note: This topics needs more discussion
  in the
  working group.]]
  
  
   I would like to start that discussion and rapidly conclude it with
  the needed
  
   changes (removal of the Editor's note or otherwise).
  
  
   My personal impression is that simplifying to just ephemeral state
 was
  
   viewed as a good idea.  What do others think?  Does anyone strongly
  
   disagree?
 
  I agree that ephemeral state is a good idea.  But I think we need to
 be
  a bit clearer on where the ephemerality lies.  That is, if the Agent
  goes away independent of the routing system, does the state go away?
  Does the RS retain the state until reboot of the network element?
 
  IMHO, the ephemeral state should be maintained with the Agent, and
 if it
  goes away (if it can go away independent from the RS), then the state
  should go away with it.
 
 
  [Alia] This is a really good point to clarify.  If the I2RS Agent goes
  away, cleaning up
  ephemeral state that it had programmed seems like it would require an
  additional gate-keeper
  to keep track of that state and do the cleaning up.   That seems painful
  to me in terms of
  complexity and storage.  I am assuming an unplanned Agent departure
  rather than an orderly
  disabling of the Agent. If the Agent simply fails, then IMHO, the
  ephemeral state should
  remain - but it is no longer owned by a particular client and could be
  overwritten...  If an Agent is
  disabled, then it can notify each client that that client's state has
  been preempted and do an
  orderly (?) removal of the state.  The gotcha with the orderly removal
  of the state would be understanding
  the dependencies of the state so that it can be cleanly removed.
 
  [Alia] So, I think we're picturing almost opposite things for this
  behavior - possibly based upon the
  particular case.   What do you think?

 See my response to Joel.  I think we have to deal with this complexity
 because if we don't and the Agent goes away, how could Clients then come
 in to remove their state?  That is, the RS retains the Agent-programmed
 state, but when the Agent reboots, it has no state.  At the worst, we
 have RS state that a Client cannot manipulate.  At best, we would open
 RS state to Clients that did not make the original change.


[Alia] I don't think that we've included locking for I2RS - so I can't see
how we'd have
RS that a client cannot manipulate.  Whether state is removed(changed back
to the
default)  or left, we will definitely have the ability for a Client to add
or change the RS
state.


 I think we have to say, to an implementor, if the Agent goes away, the
 RS must handle cleaning up all state installed by that Agent.


[Alia] I think that it could be either way - that the state remains but can
be overwritten
or that the RS has to clean up the state.  I'm concerned that in the RS
cleans up the state
case, there is no way for the Client to learn that its state has been
removed (assuming a
failure on the part of the Agent rather than an orderly removal).  I'd
prefer to see the state
remain for that reason for the Agent-failure case.  What do you think?

Alia



 Joe

 
  Alia
 
  
  
   Thanks,
  
   Alia (WG-chair hat off)
  
  
  
   ___
   i2rs mailing list
   i2rs@ietf.org mailto:i2rs@ietf.org
   https://www.ietf.org/mailman/listinfo/i2rs
  
 
 
  --
  Joe Marcus Clarke, CCIE #5384, |  |
  SCJP, SCSA, SCNA, SCSECA, VCP|  |
  Distinguished Services Engineer ..:|::|:..
  Phone: +1 (919) 392-2867 tel:%2B1%20%28919%29%20392-2867 c
  i s c o  S y s t e m s
  Email: jcla...@cisco.com mailto:jcla...@cisco.com
 
 
 
 
 


 --
 Joe Marcus Clarke, CCIE #5384, |  |
 SCJP, SCSA, SCNA, SCSECA, VCP|  |
 Distinguished Services Engineer ..:|::|:..
 Phone: +1 (919) 392-2867 c i s c o  S y s t e m s
 Email: jcla...@cisco.com

Re: [i2rs] Architecture Discussion 2: Persistence (ephemeral vs. permanent)

[Alia Atlas]

Hi Joe,

More in-line (good to have the conversation)

On Thu, Sep 12, 2013 at 11:44 AM, Joe Marcus Clarke jcla...@cisco.comwrote:

 On 9/12/13 11:31 AM, Alia Atlas wrote:
  [Alia] I don't think that we've included locking for I2RS - so I can't
  see how we'd have
  RS that a client cannot manipulate.  Whether state is removed(changed
  back to the
  default)  or left, we will definitely have the ability for a Client to
  add or change the RS
  state.

 Fair enough.

 
 
  I think we have to say, to an implementor, if the Agent goes away,
 the
  RS must handle cleaning up all state installed by that Agent.
 
 
  [Alia] I think that it could be either way - that the state remains but
  can be overwritten
  or that the RS has to clean up the state.  I'm concerned that in the RS
  cleans up the state
  case, there is no way for the Client to learn that its state has been
  removed (assuming a
  failure on the part of the Agent rather than an orderly removal).  I'd
  prefer to see the state
  remain for that reason for the Agent-failure case.  What do you think?

 I think the risk of an Agent reboot allowing Client B to change Client
 A's state warrants the RS cleanup.


[Alia] The risk that client B comes and changes the state after an Agent
reboot justifies the RS cleanup of that state before??  Remember that
Client A and B aren't supposed to be overwriting each other's data.  We've
defined that as an error case and that policy between the clients should
prevent it.


 Plus, if the Client is subscribed to a pub-sub bus then it could
 presumably learn about an Agent cold start via a published message.  At
 that point, the client could re-establish its state to the Agent.


[Alia] Hmm, I know there was a draft discussed about pub-sub methods in
general - but I don't think that we've really nailed down how pub-sub would
work.  Absent anything, I'd assume that the I2RS agent is whom the client
registers with to get its notifications.  Now, if we want to have a
different system being a bus (with the scale implications there), that
might be different - but I don't think we've really talked about that.  So,
my assumption is that the Agent provides the notifications to Clients that
have registered - and when the Agent reboots, there are no Clients
registered to get the notifications.  If you have a different model (or
different thoughts on what to do for the pub-sub), want to start that
discussion (perhaps in a different thread)?


 If the Client is not part of the bus, it could periodically connect to
 the Agent and learn that it was rebooted via the protocol...yeah, this
 sounds a bit like SNMP, but it seems reasonable to me.


[Alia] It doesn't sound reasonable to me... at least not to avoid what
should be an error condition.  Can we discuss more?  Do you have additional
justification for the significant added complexity.

Regards,
Alia



 Joe

 --
 Joe Marcus Clarke, CCIE #5384, |  |
 SCJP, SCSA, SCNA, SCSECA, VCP|  |
 Distinguished Services Engineer ..:|::|:..
 Phone: +1 (919) 392-2867 c i s c o  S y s t e m s
 Email: jcla...@cisco.com


 

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

[i2rs] General Architecture Discussion

[Alia Atlas]

(WG-Chair hat off)

I'd like to get more feedback on draft-ietf-i2rs-architecture-00 - down to
the editorial - so that we can revise it and, ideally, have it ready to
progress very soon.

Towards that end, I've sent email to start up different discussions based
upon the Editors' Notes in the draft.   I'd also welcome discussion and
comments on other topics in the architecture on this thread.

Thanks,
Alia
___
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs