Re: [netmod] New Version Notification for draft-acee-rtgwg-vrrp-rfc8347bis-03.txt

[Yingzhen Qu]

Hi,

Speaking as an individual contributor, I'm leaning toward option 3. In case
someone implemented RFC 8347, they can choose whether to implement the new
model.

Thanks,
Yingzhen

On Fri, Mar 1, 2024 at 12:43 PM Acee Lindem  wrote:

> This BIS document updates the YANG model with IETF inclusive language
> guidelines as was done with the VRRP protocol specification itself.
>
> [image: ietf-logo-card.png]
>
> Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6
> 
> datatracker.ietf.org
> 
> 
>
>
> It currently doesn’t conform to YANG backward guidelines. There are
> basically three options:
>
> 1. Treat the correction of non-inclusive language as necessary bug fix
> and allow non-backward compatible changes.
> 2. Keep all the old non-inclusive data leaves in the model with
> deprecated status. At some point in future, these could be removed in a new
> document.
> 3. Make this a completely new model - ietf-vrrp-2.yang.
>
> The current individual draft is based on option 1. I had a conversation
> with Lou and he suggested the 3 third option.
>
> What are people’s opinion on this? Option 2 is my least favorite since it
> doesn’t complete the job and given how long IETF document take (especially
> YANG models), I probably won’t be actively participating long enough for
> the draft which removes the deprecated options.
>
> Thanks,
> Acee
>
> On Mar 1, 2024, at 15:31, internet-dra...@ietf.org wrote:
>
> A new version of Internet-Draft draft-acee-rtgwg-vrrp-rfc8347bis-03.txt has
> been successfully submitted by Acee Lindem and posted to the
> IETF repository.
>
> Name: draft-acee-rtgwg-vrrp-rfc8347bis
> Revision: 03
> Title:A YANG Data Model for the Virtual Router Redundancy Protocol
> (VRRP)
> Date: 2024-03-01
> Group:Individual Submission
> Pages:44
> URL:
> https://www.ietf.org/archive/id/draft-acee-rtgwg-vrrp-rfc8347bis-03.txt
> Status:
> https://datatracker.ietf.org/doc/draft-acee-rtgwg-vrrp-rfc8347bis/
> HTML:
> https://www.ietf.org/archive/id/draft-acee-rtgwg-vrrp-rfc8347bis-03.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-acee-rtgwg-vrrp-rfc8347bis
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-acee-rtgwg-vrrp-rfc8347bis-03
>
> Abstract:
>
>   This document describes a data model for the Virtual Router
>   Redundancy Protocol (VRRP).  Both versions 2 and 3 of VRRP are
>   covered.
>
>   The VRRP terminology has been updated conform to inclusive language
>   guidelines for IETF technologies.  The IETF has designated National
>   Institute of Standards and Technology (NIST) "Guidance for NIST Staff
>   on Using Inclusive Language in Documentary Standards" for its
>   inclusive language guidelines.
>
>   This document obsoletes RFC 8347.
>
>
>
> The IETF Secretariat
>
>
>
> ___
> rtgwg mailing list
> rt...@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Lsr] I-D Action: draft-ietf-lsr-ospfv3-extended-lsa-yang-10.txt

[Yingzhen Qu]

Hi Rob,

Thanks for the thoughtful proposal, and I support it.

One thing to confirm, for models that may become RFCs in the next two years and 
where the IP address doesn’t support zones, "ip-address” should still be used. 
Correct?

Thanks,
Yingzhen


> On Apr 11, 2022, at 10:06 AM, Rob Wilton (rwilton) 
>  wrote:
> 
> Hi all,
> 
> Thanks for the comments on this thread so far.  It would be nice if we are 
> able to come to some sort of rough consensus to a solution.
> 
> I think that there is consensus that the YANG type ip-address (and the v4/v6 
> versions) are badly named as the prominent default type name has been given 
> to the unusual variant of including zone information.
> 
> Based on the comments on this thread, it also seems likely to me that most of 
> the usages of ip-address in YANG RFCs is likely to be wrong, and the 
> intention was that IP addresses without zones was intended.  At a rough 
> count, of the published RFC YANG models at github 
> YangModels/standard/ietf/RFC/ to be:
>   86 uses of ip-address
>   68 uses of ipv4-address
>   66 uses of ipv6-address
> 
>   1 use of ip-address-no-zone
>   4 uses of ipv4-address-no-zone
>   4 uses of ipv6-address-no-zone
> 
> These types appear in 49 out of the 141 YANG modules published in RFCs.  At a 
> quick guess/check it looks like these 49 YANG modules may appear in 40-50 
> RFCs.
> 
> As mentioned previously, it is also worth comparing this to the OpenConfig 
> YANG modules:
> They have redefined ip-address (and v4/v6 variants) to exclude zone 
> information and have defined separate types include zone information.
> There are no explicit uses of the "-zoned" variants of OpenConfig IP 
> addresses in the latest OpenConfig github repository.  However, approximately 
> a third of the IP address types are still to the ietf-inet-types.yang rather 
> than openconfig-inet-types.yang, so in theory some of those 58 entries could 
> still intentionally be supporting zoned IP addresses, but I would expect that 
> the vast majority would not.
> I do see some strong benefit if this basic type being defined in the same way 
> in both IETF and OC YANG, and I believe that the OC folks have got the 
> definition right.
> 
> I see that some are arguing that the zone in the ip-address definition is 
> effectively optional, and implementations are not really obliged to implement 
> it.  I don't find that argument compelling, at least not with the current 
> definition of ip-address in RFC 6991.  I see a clear difference between a 
> type defined with an incomplete regex that may allow some invalid values and 
> a type that is explicitly defined to included additional values in the 
> allowable value space.  Further, I believe that a client just looking at the 
> YANG module could reasonably expect a server that implements a data node 
> using ip-address would be expected to support IP zones, where they are 
> meaningful, or otherwise they should deviate that data node to indicate that 
> they don't conform to the model.
> 
> We also need to be realistic as to what implementations will do.  They are 
> not going to start writing code to support zones just because they are in the 
> model.  They will mostly reject IP addresses with zone information.  Perhaps 
> some will deviate the type to ip-address-no-zone, but probably most won't.
> 
> The option of respinning approx. 40-50 RFCs to fix this doesn't feel at all 
> appealing.  This would take a significant amount of time/effort and I think 
> that we will struggle to find folks who are willing to do this.  Although 
> errata could be used to point out the bug, then can't be used to fix it, all 
> the errata would be "hold for document update" at best.  Further, during the 
> time that it would take us to fix it, it is plausible that more incorrect 
> usages of ip-address will likely occur (but perhaps could be policed via 
> scripted checks/warnings).
> 
> 
> I still feel the right long-term solution here is to get to a state where the 
> "ip-address" type means what 99% of people expect it to mean, i.e., excluding 
> zone information.
> 
> Given the pushback on making a single non-backwards compatible change to the 
> new definition, I want to ask whether the following might be a possible path 
> that gains wider consensus:
> 
> (1) In RFC 6991 bis, I propose that we:
> (i) define new ip-address-with-zone types (and v4 and v6 versions) and keep 
> the -no-zone versions.
> (ii) we change the description of "ip-address" to indicate:
> - Although the type allows for zone information, many implementations are 
> unlikely to accept zone information in most scenarios (i.e., so the 
> description of the type more accurately reflects reality).
> - A new ip-address-with-zone type has been introduced to use where zoned IP 
> addresses are required/useful, and models that use ip-address with the 
> intention of supporting zoned IP addresses MUST migrate to 
> ip-address-with-zone.
> - In the 

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Yingzhen Qu]

Hi Reshad,

Thanks for the link to verify JSON, it’s very helpful.

I’ve uploaded version -07. Please let me know if you have any comments.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 8:34 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

The JSON example doesn’t seem ok because it only contains 1 edit entry. To 
confirm I went to 
https://jsonlint.com/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjsonlint.com%2F=02%7C01%7Cyingzhen.qu%40futurewei.com%7Ce9baa6c2aeee43ef078d08d8616872b9%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637366448544225811=1MfsJLUqKllzfkYO6xAYy%2FZlOq5Prq6MHVXi1sa6VW4%3D=0>
 and it 1st complained about missing comma after the } for source-value and 
when I fixed that it complained about Duplicate key ‘edit-id’.

FYI, the JSON block below passed the lint check.

Regards,
Reshad.

  {
  "ietf-nmda-compare:output": {
"differences": {
  "ietf-yang-patch:yang-patch": {
"patch-id": "interface status",
"comment": "diff between intended (source) and 
operational",
"edit": [
 {
"edit-id": "1",
"operation": "replace",
"target": 
"/ietf-interfaces:interface=eth0/enabled",
"value": {
  "ietf-interfaces:interface/enabled": 
"false"
},
"source-value": {
  "ietf-interfaces:interface/enabled": 
"true",
  "@ietf-interfaces:interface/enabled": 
{
"ietf-origin:origin": 
"ietf-origin:learned"
  }
}
  },
  {
"edit-id": "2",
"operation": "create",
"target": 
"/ietf-interfaces:interface=eth0/description",
"value": {
  
"ietf-interface:interface/description": "ip interface"
}
  }
]
  }
}
  }
  }

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 10:47 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for the example. I modified the XML example as you suggested. The 
JSON example looks ok to me. Also fixed the nit to reference RFC 6991.

New generated txt file attached, please let me know if you see more issues.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 4:58 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

     list edit {
   key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
 description
   "Arbitrary string index for the edit.
Error messages returned by the server that pertain
to a specific edit will be identified by this value.";
   }


If you take a look at A.1.1 of RFC8072, there is an example with multiple edit 
elements.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 1:07 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" 

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Yingzhen Qu]

Hi Reshad,

Thank you for the example. I modified the XML example as you suggested. The 
JSON example looks ok to me. Also fixed the nit to reference RFC 6991.

New generated txt file attached, please let me know if you see more issues.

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Friday, September 25, 2020 at 4:58 AM
To: Yingzhen Qu , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Yingzhen,

Yes I believe this part is broken, since you have multiple edit-id elements for 
1 edit element, below is the YANG snippet from RFC8072.

 list edit {
   key edit-id;
   ordered-by user;

   leaf edit-id {
 type string;
 description
   "Arbitrary string index for the edit.
Error messages returned by the server that pertain
to a specific edit will be identified by this value.";
   }


If you take a look at A.1.1 of RFC8072, there is an example with multiple edit 
elements.

Regards,
Reshad.

From: Yingzhen Qu 
Date: Friday, September 25, 2020 at 1:07 AM
To: "Reshad Rahman (rrahman)" , Alexander L Clemm 
, "yang-doct...@ietf.org" 
Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04

Hi Reshad,

Thank you for your review.

About the example, in RFC 8072, in the list “edit”, each edit is identified by 
“edit-id”. So the example looks like:

   1
   …..
   2
  ….

Do you mean this part is broken?

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Tuesday, September 22, 2020 at 6:07 AM
To: Alexander L Clemm , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04
Resent-From: 
Resent-To: , , , 
, , , 
, , , Joel Jaeggli 
, 
Resent-Date: Tuesday, September 22, 2020 at 6:07 AM

Hi Alex,

Thank you for addressing my comments.

I checked rev-06, and I believe the XML and JSON output in the example is 
broken: there is a single “edit” element with multiple “edit-id” elements. I 
believe there should be multiple “edit” elements.

The only “nit” is that leaf-xpath-filter references 6021 instead of 6991 (as 
you correctly pointed out in your response).
   leaf xpath-filter {
 if-feature nc:xpath;
 type yang:xpath1.0;
 description
   "This parameter contains an XPath expression
identifying the portions of the target
datastore to retrieve.";
 reference "RFC 6021: Common YANG Data Types";
   }

> Issues
> 1.YANG model P8, for “leaf xpath-filter”, add 
> reference to RFC6021. There should also be a normative reference to RFC6021 
> (as per RFC8407)
 Thanks.  Adding reference to 6991 (as 6021 is obsoleted). 

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:48 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Thank you!

I just uploaded rev -06.

--- Alex
On 9/18/2020 12:47 PM, Reshad Rahman (rrahman) wrote:
Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm <mailto:lud...@clemm.org>
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" <mailto:rrah...@cisco.com>, 
"yang-doct...@ietf.org"<mailto:yang-doct...@ietf.org> 
<mailto:yang-doct...@ietf.org>
Cc: "last-c...@ietf.org"<mailto:last-c...@ietf.org> 
<mailto:last-c...@ietf.org>, 
"netmod@ietf.org"<mailto:netmod@ietf.org> 
<mailto:netmod@ietf.org>, 
"draft-ietf-netmod-nmda-diff@ietf.org"<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
 
<mailto:draft-ietf-netmod-nmda-diff@ietf.org>
Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"

Re: [netmod] [yang-doctors] Yangdoctors last call review of draft-ietf-netmod-nmda-diff-04

[Yingzhen Qu]

Hi Reshad,

Thank you for your review.

About the example, in RFC 8072, in the list “edit”, each edit is identified by 
“edit-id”. So the example looks like:

   1
   …..
   2
  ….

Do you mean this part is broken?

Thanks,
Yingzhen

From: "Reshad Rahman (rrahman)" 
Date: Tuesday, September 22, 2020 at 6:07 AM
To: Alexander L Clemm , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04
Resent-From: 
Resent-To: , , , 
, , , 
, , , Joel Jaeggli 
, 
Resent-Date: Tuesday, September 22, 2020 at 6:07 AM

Hi Alex,

Thank you for addressing my comments.

I checked rev-06, and I believe the XML and JSON output in the example is 
broken: there is a single “edit” element with multiple “edit-id” elements. I 
believe there should be multiple “edit” elements.

The only “nit” is that leaf-xpath-filter references 6021 instead of 6991 (as 
you correctly pointed out in your response).
   leaf xpath-filter {
 if-feature nc:xpath;
 type yang:xpath1.0;
 description
   "This parameter contains an XPath expression
identifying the portions of the target
datastore to retrieve.";
 reference "RFC 6021: Common YANG Data Types";
   }

> Issues
> 1.YANG model P8, for “leaf xpath-filter”, add 
> reference to RFC6021. There should also be a normative reference to RFC6021 
> (as per RFC8407)
 Thanks.  Adding reference to 6991 (as 6021 is obsoleted). 

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:48 PM
To: "Reshad Rahman (rrahman)" , "yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" , "netmod@ietf.org" 
, "draft-ietf-netmod-nmda-diff@ietf.org" 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Thank you!

I just uploaded rev -06.

--- Alex
On 9/18/2020 12:47 PM, Reshad Rahman (rrahman) wrote:
Hi Alex,

This addresses my comment/concern.

Regards,
Reshad.

From: Alexander L Clemm 
Date: Friday, September 18, 2020 at 3:43 PM
To: "Reshad Rahman (rrahman)" , 
"yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" 
, 
"netmod@ietf.org" 
, 
"draft-ietf-netmod-nmda-diff@ietf.org"
 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

okay, so let's add the following then to section 4, in the explanation of the 
"differences" output parameter:

"When a datastore node in the source of the comparison is not present in the 
target of the comparison, this can be indicated either as a "delete" or as a 
"remove" in the patch as there is no differentiation between those operations 
for the purposes of the comparison.  "

And update the description as follows:

 container differences {
  description
   "The list of differences, encoded per RFC8072 with an
 augmentation to include source values where
 applicable.  When a datastore node in the source is
 not present in the target, this can be indicated either
 as a 'delete' or as a 'remove' as there is no difference
 between them for the purposes of the comparison.";
...

I will post this in a -06 shortly.  Please let us know if this addresses your 
concerns or if there is anything else.

Thanks!

--- Alex


On 9/18/2020 5:57 AM, Reshad Rahman (rrahman) wrote:
Hi Alex,

I think the only “problem” with using both “remove” and “delete” is that it 
could be confusing (when should one be used and not the other). Adding some 
text to say they’re the same for the diff operation is good enough for me.

Regards,
Reshad.

From: Alexander L Clemm 
Date: Tuesday, September 15, 2020 at 7:31 PM
To: "Reshad Rahman (rrahman)" , 
"yang-doct...@ietf.org" 

Cc: "last-c...@ietf.org" 
, 
"netmod@ietf.org" 
, 
"draft-ietf-netmod-nmda-diff@ietf.org"
 

Subject: Re: [yang-doctors] [netmod] Yangdoctors last call review of 
draft-ietf-netmod-nmda-diff-04


Hi Reshad,

re: question 1: As you indicate, there may be no distinction between indicating 
a "remove" or a "delete" in the patch.  Right now it would be acceptable to 
return either.  If we want to eliminate this freedom, which one 

Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags

[Yingzhen Qu]

Hi,

Here is my understanding of the node-tag draft. Please correct me if there is 
any misunderstanding.

This draft is an idea extension of the module-tag draft. Module-tag is to tag 
or categorize modules, for example, tag “ietf:routing” can be used to “group” 
together modules like ietf-routing, ietf-ospf etc, so users know easily that 
these modules are from the same category, and using this tag, they can further 
find all “ietf:routing” modules as ietf-isis etc. A tag is not meant to add or 
change functionalities of existing modules. Similarly, node-tag is to add tags 
at node level, like Lou’s point (b), it may provide some general functions.

I support the WG to adopt this idea and continue to work on it. Of course the 
draft needs some clarifications and good examples.

Thanks,
Yingzhen
From: netmod  on behalf of Lou Berger 

Date: Monday, August 31, 2020 at 6:29 AM
To: Qin Wu , Kent Watsen , 
"netmod@ietf.org" , "draft-tao-netmod-yang-node-t...@ietf.org" 

Subject: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags
Resent-From: 


Qin,

Thank you for your reply.I think you have two points below (a) tags to define 
metric type and (b) object-specific tags

For me, I believe I agree with Juergen's comments, i.e.,  that metric type 
definition is not metadata and belongs in the module definition.

On the other topic (b) object-specific tags is an interesting idea and may 
provide general utility.  (as contributor) once separated from the metrics 
discussion, this seems like an idea worth discussing in the WG to see if there 
is interest in this added capability.

Lou



On August 30, 2020 5:01:28 AM Qin Wu 
 wrote:
Thanks Lou for valuable comments, please see reply inline below.
发件人: Lou Berger [mailto:lber...@labn.net]
发送时间: 2020年8月30日 2:40
收件人: Kent Watsen ; 
netmod@ietf.org; 
draft-tao-netmod-yang-node-t...@ietf.org
主题: Re: [netmod] Adoption poll for draft-tao-netmod-yang-node-tags


Hi,

A couple of comments:

- As a co-author or YANG Module Tags, I'm thrilled to see it being 
used/augmented by this document, but I'm not clear on how the metric and 
operation type tags are to be used.  To me these seem to be best defined by the 
modules themselves, e.g., does a value represent an average /sum/min/max value 
or the scale of the value, and not as tag meta data.

[Qin]:Just to clarify, defining metric and operation type by modules themselves 
may cause revising all the existing published modules we expect to tag, or 
creating the same number of new modules (augment from the existing published 
modules) as the number of targeted existing modules, which is not scalable and 
desirable. So we abandon this option in our implementation design.

The data object tags like metric and operation type tag don't introduce any new 
data nodes into existing modules and can tag any performance metric related 
data object within published modules, standard modules, native modules without 
module name change. The data object tag can not be used to tag any one of 
targeted modules (ietf-geo-location defined in draft-ietf-netmod-geo-location 
or ietf-ip in RFC8344) which doesn't include performance metric related data 
node.

Regarding operation type tag, take ietf-interfaces in RFC8343 as an example, 
ietf-interfaces include interface statistics data object which can be seen as 
performance metric related data objects,

   +--ro statistics

  +--ro discontinuity-timeyang:date-and-time

  +--ro in-octets?yang:counter64

  +--ro in-unicast-pkts?  yang:counter64

  +--ro in-broadcast-pkts?yang:counter64

  +--ro in-multicast-pkts?yang:counter64

  +--ro in-discards?  yang:counter32

  +--ro in-errors?yang:counter32

  +--ro in-unknown-protos?yang:counter32

  +--ro out-octets?   yang:counter64

  +--ro out-unicast-pkts? yang:counter64

  +--ro out-broadcast-pkts?   yang:counter64

  +--ro out-multicast-pkts?   yang:counter64

  +--ro out-discards? yang:counter32

  +--ro out-errors?   yang:counter32

however these statistics doesn't tell you whether in-errors is current value or 
average value or total value, so does count related data objects defined in 
ietf-dhcpv6-server of draft-ietf-dhc-dhcpv6-yang

+--ro solicit-count?   uint32

+--ro advertise-count? uint32

+--ro request-count?   uint32

+--ro confirm-count?   uint32

+--ro renew-count? uint32

+--ro rebind-count?uint32

+--ro reply-count? uint32

Re: [netmod] [Technical Errata Reported] RFC8349 (6251)

[Yingzhen Qu]

Sorry, had to resend the email with reduced recipients because it was held due 
to too many recipients. 

Thanks,
Yingzhen

On 8/14/20, 2:50 PM, "Yingzhen Qu"  wrote:

Hi Tarek,

The proposed change separates IP routes and MPLS routes, and it works fine 
with RFC 8349. All other MPLS category augmentations can follow this style. 

One question, my understanding is MPLS RIB will list all MPLS routes, such 
as mpls-ldp routes and mpls-static routes. A comparison is IPv4 address-family 
RIB lists all routes calculated by different routing protocols (BGP, OSPF etc), 
and ietf-ospf.yang augments "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" 
with OSPF specific attributes. However, I don't see this relationship between 
the base MPLS model and for example MPLS-LDP model, the binding state is in 
container IPv4 and IPv6 address family, and this is a bit like OSPF local-rib. 
The base MPLS routes is not showing this binding information (mpls-ldp model 
may augment this although this is not critical.). Am I missing or 
misunderstanding something here?

In RFC 8349, "leaf source-protocol" is mandatory, and its type is 
identityref of routing-protocol. I don't see this is defined in the base MPLS, 
mpls-ldp, or mpls-static model, so what will the "source-protocol" be?

Thanks,
Yingzhen 

On 8/14/20, 9:25 AM, "Tarek Saad"  wrote:

Hi Acee and Tom,

The authors of ID: draft-ietf-mpls-base-yang met and we discussed the 
points below.
We understand that RFC8349 defines an AF-agnostic model for RIBs. 
RFC8349 defined only two types of RIBs (IPv4 and IPv6 RIBs), but we envision 
other types of RIBs too (e.g. L2 RIB, MCAST RIB, etc.), in addition to MPLS RIB 
-- and we hope all such RIBs indeed leverage the generic RIB model introduced 
in RFC8349.

We revisited Acee's suggestion and made a small modification (on top of 
it) that makes IP routes, MPLS routes (and possibly L2 or MCAST routes in 
future) - all have similar MPLS augmentation (in terms of local-label) while 
still adhering with RFC8349 to augment with leaf destination-prefix.

augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" {
  when "derived-from-or-self(../../rt:address-family, "
 + "'mpls:mpls')" {
description
  "This augment is valid only for native MPLS routes.";
  }
  description
"This leaf augments a native MPLS route.";
  leaf destination-prefix {
type leafref {
  path "../local-label";
}
description
  "MPLS destination prefix.";
  }
}

We follow same approach for the active route RPC and continue to use a 
leaf "destination-address" as input (that points to a local-label leaf).
If this is acceptable, we believe the errata 6251 can be rejected and 
we'll proceed with the change in the MPLS RIB model.

Regards,
Tarek (for authors)

On 8/11/20, 9:08 AM, "Acee Lindem (acee)"  wrote:

[External Email. Be cautious of content]


Hi Tom, Draft Authors,

The draft could easily be fixed. You just need to:

  1. Expand on the single sentence in section 2.1 on the need for 
non-IP MPLS routes. Given that the draft wasn't modeled correctly, this wasn't 
apparent to most of the reviewers.
  2. Add an MPLS AF only augmentation (enforced via a when 
statement) to each route for the MPLS AF specific destination-prefix or 
destination-address.
  3. Limit the current local-label augmentation to non-MPLS AFs.
  4. Limit the active-route augmentation to AF MPLS and change the 
input to destination-address.

Thanks,
Acee

On 8/11/20, 6:10 AM, "tom petch"  wrote:

From: Acee Lindem (acee) 
Sent: 11 August 2020 10:47

Hi Tom,
I fully understood your original comment. There are other 
problems with this model. See inline.

On 8/11/20, 4:59 AM, "tom petch"  wrote:

Tarek

Picking up on an earlier point,


From: Tarek Saad 
Sent: 10 August 2020 21:23

Hi Acee,

The existing RPC is used to query (defined AFIs=IPv4/IPv6) 
RIB to return the matching active route identified by a "destination address".
The MPLS module is trying to reuse this RPC so to query the

Re: [netmod] draft-ietf-netmod-nmda-diff - IPR verfication request

[Yingzhen Qu]

I'm not aware of any IPR besides the one disclosed.

Thanks,
Yingzhen


On 2/25/20, 10:42 PM, "Jeff Tantsura"  wrote:

Joel,

No, I'm not aware of any IPR that applies to this draft.

Cheers,
Jeff

> On Feb 17, 2020, at 11:44, Joel Jaeggli  wrote:
> 
> No, I'm not aware of any IPR that applies to this draft


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

Re: [netmod] Doubts about static routes in RFC 8349

[Yingzhen Qu]

Hi Martin,

I agree with what Acee explained. Theoretically it's possible that in operation 
state an implementation can expand this into several route entries, but that's 
not how typically a RIB is implemented. One reason is that it will make the 
routing table look up much harder and inefficient.

Thanks,
Yingzhen

-Original Message-
From: rtgwg [mailto:rtgwg-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Wednesday, April 03, 2019 5:21 AM
To: Martin Bjorklund 
Cc: netmod@ietf.org; rt...@ietf.org
Subject: Re: [netmod] Doubts about static routes in RFC 8349

Hi Martin, 

On 4/3/19, 7:57 AM, "Martin Bjorklund"  wrote:

"Acee Lindem (acee)"  wrote:
> Hi Sasha, 
> 
> On 4/3/19, 7:27 AM, "Alexander Vainshtein"
>  wrote:
> 
> Martin,
> Lots of thanks for a prompt response.
> 
> My reading of your response is that, if you need multiple static
> routes with the same destination but different next hops, you
> configure them as a single route with next-hop-list, but what you see
> when you retrieve the RIB may be multiple individual routes, each with
> its own simple next hop. Or it may be something else, since no keys
> have been defined in the read-only representation of the RIB.
> 
> Is my reading correct?
> 
> No - you'd see a single route and next-hop-list with the alternatives
> when it is retrieved.

Do you think it would be a violation of the spec if an implementation
expanded this into several route entries?  If yes, is this specified?

Normally, a given RIB client, e.g., static,  would install a single route with 
one or more next-hops in the global RIB. If present, multiple routes for the 
same destination would come from different RIB clients. The RIB active route 
the is the route with the lowest preference value (more preferred). Since the 
read-only lists do not have indices, I don't see how'd we'd enforce this. 
However, an implementation supporting any other structure would be highly 
irregular. 

Thanks,
Acee


/martin



>  
> Thanks,
> Acee
>  
> 
> Regards, and lots of thanks in advance,
> Sasha
> 
> Office: +972-39266302
> Cell:  +972-549266302
> Email:   alexander.vainsht...@ecitele.com
> 
> 
> -Original Message-
> From: Martin Bjorklund  
> Sent: Wednesday, April 3, 2019 2:05 PM
> To: Alexander Vainshtein 
> Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> Subject: Re: [netmod] Doubts about static routes in RFC 8349
> 
> Hi,
> 
> 
> Alexander Vainshtein  wrote:
> > Martin,
> > 
> > Lots of thanks for an interesting input.
> > 
> > I have noticed that Appendix A in RFC
> > 8349  defines the 
key 
> > for static IPv4 and IPv6 unicast routes as “destination-prefix”.
> 
> Right (to be precise, the key is defined in the YANG models in section
> 8 and 9).
> 
> 
> > draft-ietf-rtgwg-
> > 
yang-rib-extend > extend-01> claims that it augments the model defined in 8349, 
> > therefore, to the best of my understanding, it uses the same key 
for 
> > station IPv4 and
> > IPv6 unicast routes.
> 
> Correct.
> 
> 
> > At the same time Appendix A in this draft does not define any keys 
for
> > the read-only RIB.
> > 
> > Can you explain this controversy?
> 
> Not sure there's a controversy.  The static route list is how you
> configure static routes, and the RIB is the operational state of all
> routes (static and others).  Two different things.
> 
> The MIB had a single table to show routes and write routes.  I don't
> think the persistency of the routes you wrote into the MIB was
> defined; perhaps these can be viewed as being "static".
> 
> 
> /martin
> 
> 
> > 
> > 
> > 
> > Regards, and lots of thanks in advance,
> > 
> > Sasha
> > 
> > 
> > 
> > Office: +972-39266302
> > 
> > Cell:  +972-549266302
> > 
> > Email:   alexander.vainsht...@ecitele.com
> > 
> > 
> > 
> > -Original Message-
> > From: Martin Bjorklund 
> > Sent: Wednesday, April 3, 2019 1:34 PM
> > To: Alexander Vainshtein 
> > Cc: a...@cisco.com; lho...@nic.cz; netmod@ietf.org; rt...@ietf.org
> > Subject: Re: [netmod] Doubts about static routes in RFC 8349
   

Re: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

[Yingzhen Qu]

I support WG adoption.

Thanks,
Yingzhen

From: netmod  on behalf of Kent Watsen 

Date: Monday, March 25, 2019 at 1:32 PM
To: "netmod@ietf.org" 
Subject: [netmod] Adoption poll for draft-chopps-netmod-geo-location-01

This email begins a 2-week adoption poll for:


https://tools.ietf.org/html/draft-chopps-netmod-geo-location-01


Please voice your support or objections before April 8.


Kent // as co-chair



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

Re: [netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

[Yingzhen Qu]

Support As coauthor.

--
Thanks,
Yingzhen
发件人：Kent Watsen
收件人：netmod@ietf.org,
时间：2018-10-01 14:48:55
主 题：[netmod] WG adoption poll for draft-clemm-netmod-nmda-diff-00

The IETF 102 in-room poll should really good support to adopt
this draft, and no objections.

This email starts an adoption poll for:

  https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff-00

Please indicate your support or objection to the adoption poll.
If objecting, please state your reasons on this thread.

Kent (and Lou and Joel)

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

Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00

[Yingzhen Qu]

Hi,

I'm not aware of any IPR that was not disclosed.

--
Thanks,
Yingzhen
发件人：Alexander Clemm
收件人：Jeff Tantsura,netmod@ietf.org,Kent Watsen,
时间：2018-10-01 18:13:47
主 题：Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00

Kent,
same here.  I am not aware of any IPR that has not been disclosed.  (I am aware 
of the IPR that was disclosed a year ago and that is on datatracker.)
--- Alex

From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Jeff Tantsura
Sent: Monday, October 01, 2018 4:07 PM
To: netmod@ietf.org; Kent Watsen 
Subject: Re: [netmod] IPR poll on draft-clemm-netmod-nmda-diff-00

Kent,

I’m not aware of any IPR that has not been disclosed.
Thanks!

Cheers,
Jeff
On Oct 1, 2018, 11:48 AM -0700, Kent Watsen 
mailto:kwat...@juniper.net>>, wrote:

This mail starts the IPR poll for draft-clemm-netmod-nmda-diff-00.

Are you aware of any IPR that applies to this draft? If so, has this IPR been 
disclosed in compliance with IETF IPR rules? Note, you do not have to be an 
author or a contributor to make everyone aware of an IPR. See RFC 3669, 3979, 
4879 and 5378 for details.

If you are listed as an author on the document, or as a contributor, please 
respond to this e-mail, indicating whether or not you are aware of any relevant 
IPRs. The response needs to be send to the NETMOD mailing list. The document 
will not advance to the next stage until a response has been received from all 
the authors and any contributors.

Kent (and Lou and Joel)


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

Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03

[Yingzhen Qu]

As co-author, I support and am not aware of any IPR.

Thanks,
Yingzhen

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Friday, October 13, 2017 10:04 AM
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] WG adoption poll draft-acee-netmod-rfc8022bis-03

As co-author, I support and am not aware of any IPR.
Thanks,
acee 

On 10/13/17, 10:37 AM, "netmod on behalf of Kent Watsen"
 wrote:

>All,
>
>Now that we have resolved the module naming issue on the list (i.e.
>that keeps the original rfc module names and updates the unwanted 
>legacy nodes to have status 'obsolete'), rather than wait for the 
>changes to be made in the individual document, we'd like to move ahead 
>with the adoption now, with the understanding that these changes will 
>be made in the -01 version of the adopted draft.
>
>This is start of a two-week poll on making 
>draft-acee-netmod-rfc8022bis-03 a working group document.  Please send 
>email to the list indicating "yes/support" or "no/do not support".  If 
>indicating no, please state your reservations with the document.  If 
>yes, please also feel free to provide comments you'd like to see 
>addressed once the document is a WG document.
>
>The poll ends Oct 27.
>
>Thanks,
>Kent (and Lou)
>
>___
>netmod mailing list
>netmod@ietf.org
>https://www.ietf.org/mailman/listinfo/netmod

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

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

Re: [netmod] Proposal to enhance the YANG tree output

[Yingzhen Qu]

Hi all,

I personally like to keep the ‘@’ and the '/' in the tree output. As we know 
that a tree may not catch all what a module is trying to do, but it can help 
users to quickly get an idea of the module's overall architecture etc. The '@' 
and the '/' is very helpful in order to understand all the mounting points.

Thanks,
Yingzhen

-Original Message-
From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Acee Lindem (acee)
Sent: Monday, September 25, 2017 9:30 AM
To: Ladislav Lhotka ; netmod@ietf.org; Martin Bjorklund 

Subject: Re: [netmod] Proposal to enhance the YANG tree output

Martin, Lada, et al,

While I don’t think we need additional annotations that Joe had prototyped (at 
least not as the default), I strongly believe we need to keep the ‘@‘ and ‘/‘ 
in the tree output for schema mount. While the former enhancement provided 
details, the schema mount tree designations are every bit as important as 
knowing, for example, whether or not a schema leaf is a presence node. 

Thanks,
Acee 


On 9/15/17, 9:56 AM, "Acee Lindem (acee)"  wrote:

>+1 - Also it is hard enough to format the tree output to fit in a draft
>w/o further annotations (even with —-tree-line-length).
>Thanks,
>Acee
>
>
>On 9/15/17, 6:21 AM, "netmod on behalf of Ladislav Lhotka"
> wrote:
>
>>Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700:
>>> Hi,
>>> 
>>> 
>>> Actually I liked the early pyang output that was concise and easy to 
>>>remember.
>>> The current format gets very cluttered and there are too many little 
>>>symbols  to remember them all.
>>
>>I agree.
>>
>>Lada
>>
>>> 
>>> 
>>> Andy
>>> 
>>> 
>>> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke  wrote:
>>> > I've been hacking on pyang, and I changed tree.py to add the enum
>>>values
>>> > for enumeration types and identiyref bases for identityref types.
>>>Here
>>> > is an example:
>>> > 
>>> > module: yang-catalog
>>> > +--rw catalog
>>> >+--rw modules
>>> >|  +--rw module* [name revision organization]
>>> >| +--rw name yang:yang-identifier
>>> >| +--rw revision union
>>> >| +--rw organization string
>>> >| +--rw ietf
>>> >| |  +--rw ietf-wg?   string
>>> >| +--rw namespaceinet:uri
>>> >| +--rw schema?  inet:uri
>>> >| +--rw generated-from?  enumeration [mib, code,
>>> > not-applicable, native]
>>> >| +--rw maturity-level?  enumeration [ratified,
>>> > adopted, initial, not-applicable]
>>> > ...
>>> >+--rw protocols
>>> >|  +--rw protocol* [name]
>>> >| +--rw name
>>> > identityref -> protocol
>>> > ...
>>> > 
>>> > My questions are:
>>> > 
>>> > 1. Is this useful?
>>> > 
>>> > 2. If so, can this be added to pyang (happy to submit a PR) and 
>>> > draft-ietf-netmod-yang-tree-diagrams?
>>> > 
>>> > 3. What changes to the output format would you recommend?
>>> > 
>>> > Thanks.
>>> > 
>>> > Joe
>>> > 
>>> > ___
>>> > netmod mailing list
>>> > netmod@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> ___
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>--
>>Ladislav Lhotka
>>Head, CZ.NIC Labs
>>PGP Key ID: 0xB8F92B08A9F76C67
>>
>>___
>>netmod mailing list
>>netmod@ietf.org
>>https://www.ietf.org/mailman/listinfo/netmod
>

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

Re: [netmod] Regarding IPR on draft-acee-netmod-rfc8022bis-02

[Yingzhen Qu]

No, I'm not aware of any IPR that applies to this draft.


Thanks,
Yingzhen

-Original Message-
From: Acee Lindem (acee) [mailto:a...@cisco.com] 
Sent: Monday, September 18, 2017 6:56 AM
To: Lou Berger <lber...@labn.net>; Ladislav Lhotka <lho...@nic.cz>; Yingzhen Qu 
<yingzhen...@huawei.com>
Cc: NetMod WG <netmod@ietf.org>
Subject: Re: Regarding IPR on draft-acee-netmod-rfc8022bis-02

As a co-author, 

No, I'm not aware of any IPR that applies to this draft.


Thanks,
Acee 

On 9/18/17, 9:48 AM, "Lou Berger" <lber...@labn.net> wrote:

>Authors, Contributors, WG,
>
>As part of the preparation for WG Last Call:
>
>Are you aware of any IPR that applies to drafts identified above?
>
>Please state either:
>
>"No, I'm not aware of any IPR that applies to this draft"
>or
>"Yes, I'm aware of IPR that applies to this draft"
>
>If so, has this IPR been disclosed in compliance with IETF IPR rules 
>(see RFCs 3669, 5378 and 8179 for more details)?
>
>If yes to the above, please state either:
>
>"Yes, the IPR has been disclosed in compliance with IETF IPR rules"
>or
>"No, the IPR has not been disclosed"
>
>If you answer no, please provide any additional details you think 
>appropriate.
>
>If you are listed as a document author or contributor please answer the 
>above by responding to this email regardless of whether or not you are 
>aware of any relevant IPR. This document will not advance to the next 
>stage until a response has been received from each author and listed 
>contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S 
>TO LINES.
>
>If you are on the WG email list or attend WG meetings but are not 
>listed as an author or contributor, we remind you of your obligations 
>under the IETF IPR rules which encourages you to notify the IETF if you 
>are aware of IPR of others on an IETF contribution, or to refrain from 
>participating in any contribution or discussion related to your 
>undisclosed IPR. For more information, please see the RFCs listed above 
>and 
>http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty.
>
>Thank you,
>NetMod WG Chairs
>
>PS Please include all listed in the headers of this message in your 
>response.
>
>
>

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

Re: [netmod] "A YANG Data Model for Routing Management" Modifications

[Yingzhen Qu (yiqu)]

Since “multi-next-hop” is a list and we need a key for a list, even choice
doesn’t work here. I’m thinking maybe we can use “0.0.0.0” for empty ip
address and “NULL” for empty interface, but it doesn’t look pretty anyway.
Especially the interface should be a reference, and it can’t be “NULL”.

Thanks,
Yingzhen

On 5/31/16, 1:29 PM, "Acee Lindem (acee)" <a...@cisco.com> wrote:

>Hi Lada, 
>If we can’t get YANG to do what we need, can we just support a choice with
>a special value of “unspecified” for the interface and address?
>Additionally, we’d need a constraint that enforces the fact that both
>interface and address cannot be “unspecified”.
>
>Thanks,
>Acee 
>
>On 5/30/16, 8:51 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
>
>>"Yingzhen Qu (yiqu)" <y...@cisco.com> writes:
>>
>>> Hi Lada,
>>>
>>> The ³multi-next-hop² is using the combination of interface and address
>>>as
>>> the list key. I know key can¹t be empty, but for next hop it¹s possible
>>> that only either interface or address is used. I¹ve been trying to
>>>figure
>>> out a better way to present this, any suggestion?
>>
>>Optional list keys were proposed for YANG 1.1:
>>
>>https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-10
>>
>>The reason that the issue Y09 was eventually rejected was that many
>>people thought it was a relatively far-reaching change. This means we
>>are left with the same options as in YANG 1.0, none of them being very
>>pretty:
>>
>>- Add a dummy opaque key, e.g.
>>
>>  list next-hop-entries {
>>key id;
>>leaf id {
>>  type uint16;
>>}
>>unique interface address;
>>...
>>  }
>>
>>- Use special value, such as empty string, to indicate that either
>>  interface or address isn't present. But since inet:ipv[46]-address
>>  cannot be empty, we would need to define the type of "address" as a
>>  union of empty string and inet:ipv[46]-address.
>>
>>Lada
>>
>>>
>>> If there is anything I can help with the modification, please let me
>>>know.
>>>
>>> Thanks,
>>> Yingzhen
>>>
>>> On 5/27/16, 4:14 AM, "Acee Lindem (acee)" <a...@cisco.com> wrote:
>>>
>>>>Hi Lada, 
>>>>
>>>>On 5/27/16, 5:42 AM, "Ladislav Lhotka" <lho...@nic.cz> wrote:
>>>>
>>>>>Hi Acee,
>>>>>
>>>>>I have a couple of questions:
>>>>>
>>>>>1. I changed "routing-protocol" -> "control-plane-protocol" (this is
>>>>>   already in GitHub). As for identities, I introduced a new base
>>>>>   identity "control-plane-protocol", and derived "routing-protocol"
>>>>>   from it. So the idea is that routing protocols will still use
>>>>>   "routing-protocol" as their base. Is it OK?
>>>>
>>>>Yes - as long as there is a single list. I¹ll pull the source today.
>>>>
>>>>>
>>>>>2. We could define identities for route types but I am still not
>>>>>   convinced that route-type should be added to ietf-routing because
>>>>>   then we can't limit the set of types for each protocol, so that,
>>>>>for
>>>>>   example, OSPF routes could carry IS-IS Level [12] routes.
>>>>
>>>>Do you mean that OSPF would install the wrong type of route? I would
>>>>see
>>>>this as a bug but not something the model itself should enforce.
>>>>
>>>>Note that OSPF can ³carry² any type of route if it is imported into
>>>>OSPF
>>>>and advertised as an AS External route.
>>>>
>>>>>
>>>>>3. The "multi-next-hop" case in rib-extend-01 uses interface and
>>>>>address
>>>>>   as keys. This means that for every next-hop *both* parameters have
>>>>>to
>>>>>   be given. Is it really intended?
>>>>
>>>>No - either or both must be specified but both are not required. I¹ll
>>>>leave this to you YANG experts.
>>>>
>>>>Thanks,
>>>>Acee
>>>>
>>>>
>>>>
>>>>>
>>>>>Thanks, Lada
>>>>>
>>>>>"Acee Lindem (acee)" <a...@cisco.com> writes:
>>>>>
>>>>>> Hi Lada, 
>>>>>&

Re: [netmod] proposed change to ietf-routing

[Yingzhen Qu (yiqu)]

Hi Lada,

For ECMP, we can actually define the next-hop as a list, so if there is
only one element in the list it¹s the simple next-hop case, and for ECMP
there are multiple elements in the list. RIB is more complete by adding
ECMP support.

Thanks,
Yingzhen

On 3/4/16, 5:00 AM, "netmod on behalf of Ladislav Lhotka"
 wrote:

>"Acee Lindem (acee)"  writes:
>
>> Hi Lada, 
>>
>> On 3/3/16, 8:01 AM, "Ladislav Lhotka"  wrote:
>>
>>>"Acee Lindem (acee)"  writes:
>>>
 Hi Lada, NETMOD WG members,

 There are actually a number of changes that we would like to
 see in the ietf-routing model:

 - Remove routing-instances since ietf-routing since it will be
   ³mounted² at different points in the device hierarchy dependent
   on the device requirements.
>>>
>>>Agreed.
>>>

 - Collapse it into one module supporting different address families
   rather 3 modules (base, IPv4, and IPv6).
>>>
>>>This is possible, but we would have to introduce a mechanism for
>>>implementations supporting only one of them. It seems to me that it is
>>>easier to select modules for base + any combination of address families,
>>>and each family module inserts appropriate stuff to right places - and
>>>there is quite a bunch of them. What you are proposing probably means
>>>the
>>>(single) module would have if-features or whens in all those places.
>>
>> Are there planned implementations required YANG models where only IPv4
>>or
>> IPv6 are supported? Maybe way off in the future, when you and I are both
>> sitting on a beach drinking beer there will be IPv6 only products but I
>> don¹t see it happening soon.
>>
>
>Maybe some experts in the embedded area could comment on this, but I
>believe in both 6LoWPAN and ZigBee IPv6-only networks are commonplace.
>
>>
>>
>>>

 - Remove the ND (RFC 4861) Router Advertisement protocol since it
   doesn¹t need to be here.
>>>
>>>Well, RFC 4861 says: "A router MUST allow for the following conceptual
>>>variables to be configured by system management."
>>>
>>>So I don't think they can be considered optional. We could perhaps move
>>>them to a submodule so that they don't clutter the main module.
>>
>> I don¹t disagree - but why are they grouped with the main RIB and infra
>> draft? Router Advertisement should be with the other RFC 4861 protocols.
>> It is out of place here.
>
>The idea is that any device that implements ietf-routing is required to
>support these configuration variables, which is what 4861 says. With a
>mechanism like Andy's packages we would have more flexibility, but for
>the time being the best solution seems to be to move RA stuff to a
>submodule.
>
>>
>>
>>
>>>

 - Support at least the next hop enhancements in
   https://tools.ietf.org/html/draft-acee-rtgwg-yang-rib-extend-00
>>>
>>>They can be added via augments, and many potential users of the routing
>>>module (hosts and simple routers) don't support them.
>>
>> Are there hosts that don¹t support at least ECMP?
>
>I am not sure. If there is consensus that ECMP is really ubiquitous,
>then we can add it.
>
>>
>>>

 - Include at least ECMP in the static route configuration.
>>>
>>>Same as in the previous case: ietf-routing provides a choice node for
>>>next-hops in both RIBs and static routes, and ECMP is explicitly
>>>mentioned as a candidate for augmentation. Why is it such a big a
>>>problem?
>>
>> It is not but as long as we are changing the model, we might as well
>> handle the predominant use cases.
>
>My concern is that other groups may come up with their favourite
>cases. Any new stuff increases the likelihood that bugs or inadequacies
>will be discovered in the module after it is published, but then it will
>be a problem due to the draconian module update rules. So I'd prefer to
>keep this module really skinny.
>
>>
>>
>>>

 - Structure consistent with the operational state recommendation.
   Even w/o having the final recommendation, this model seems to
   branch between config and state at way too high a level.
>>>
>>>Could you outline the concrete changes that you propose here? The most
>>>significant part of state data in this module is the list of RIBs, and I
>>>don't see any way how it can be bundled with configuration somewhere
>>>deeper in the hierarchy.
>>
>> I guess we will discuss this in upstate call next week. However, no
>>matter
>> what solution we come up with, it seems keeping the derived state closer
>> to intended/applied config is better.
>
>OK.
>
>Lada
>
>>
>> Thanks, 
>> Acee 
>>
>>
>>>
>>>Lada
>>>

 Thanks,
 Acee


 On 2/26/16, 8:36 AM, "netmod on behalf of Ladislav Lhotka"
  wrote:

>Hi,
>
>as a part of synchronization of the routing data models that are being
>developed by the NETMOD and RTG working groups, the authors