Subject: [yang-doctors] How to restrict to have single control-plane-protocol instance

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 8 Feb 2018 01:34:42 +0000

Hi YDs,

MSDP YANG authors want to enforce single-instance of MSDP control-plane protocol. The when “rt:type = ‘msdp’“ allows multiple control-pane-protocol instances as long as they have different rt:name. The only workaround I thought of is to have a when statement on the name in the top level container. This would still multiple control-plane-protocol instance of type msdp but restricts the name to a fixed name (msdp-protocol  in this case) for the top level msdp container to exist. Any suggestions on how to do this better?

Regards,
Reshad.

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol" {
     when "rt:type = ‘msdp’"  {
      description
        "….”;
    }
    description "….";

    container msdp {
      when "../rt:name = ‘msdp-protocol’"  {
        description
          "….";
      }
      description "MSDP top level container.";

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Monday, February 5, 2018 at 6:25 PM
To: Xufeng Liu <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Mahesh Sivakumar (masivaku)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "Acee Lindem (acee)" <[email-masked]>
Subject: Re: Hi all, about the modification of MSDP YANG

Hi Sandy and Xufeng,

I understand that you want only 1 MSDP instance but I don’t think that justifies /rt:routing/rt:control-plane-protocols. If we do that we will end up with all single-instance protocols under /rt:routing/rt:control-plane-protocols and all the multi-instance ones under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol.

I am not sure what’s the best way to enforce single-instance, I can check with the other YDs on this topic. One way it can be done is as follows (I’ve added the when statement in bold to existing BFD model), it enforces that the protocol name is ‘bfdv1’. So multiple instances with rt:type=bfd-types:bfdv1 could be created, but only one of these instances can have the bfd container. This is probably not the best way but the point is that IMO protocols have to go under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol.

Regards,
Reshad.

  augment "/rt:routing/rt:control-plane-protocols/"
        + "rt:control-plane-protocol" {
     when "rt:type = 'bfd-types:bfdv1'"  {
      description
        "This augmentation is only valid for a control-plane protocol
         instance of BFD (type 'bfdv1').";
    }
    description "BFD augmentation.";

    container bfd {
      when "../rt:name = 'bfdv1'"  {
        description
          "This augmentation is only valid for a control-plane protocol
           instance of BFD (type 'bfdv1').";
      }
      description "BFD top level container.";

From: Xufeng Liu <[email-masked]>
Date: Monday, February 5, 2018 at 9:38 AM
To: "[email-masked]" <[email-masked]>
Cc: "Reshad Rahman (rrahman)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Mahesh Sivakumar (masivaku)" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Hi all, about the modification of MSDP YANG

Hi Sandy,

Thanks for the updates.

In RFC8022bis, the rt:type is defined under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol. If we augment /rt:routing/rt:control-plane-protocols, the “when” statement will not be valid, because it cannot find the rt:type. I don’t think that we need the “when” statement. The container with “presence” will serve the purpose of the identity. We can simply take out the “when” statement and the definition of the MSDP identity.

Thanks,
- Xufeng

From: [email-masked] [mailto:[email-masked]]
Sent: Monday, February 5, 2018 3:36 AM
To: Xufeng Liu <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Hi all, about the modification of MSDP YANG

Hi Xufeng and Reshad,

I am sorry for forgetting the point. I updated the YANG model.

If no one has comments on it I'd like to submit the new version. :-)

Thanks,

Sandy
原始邮件
发件人： <[email-masked]<mailto:[email-masked]>>;
收件人： <[email-masked]<mailto:[email-masked]>>;张征00007940; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;徐本崇10065053; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
日 期 ：2018年02月03日 01:21
主 题 ：RE: Hi all, about the modification of MSDP YANG
Hi Sandy and Reshad,

The reason that we used to augment /rt:routing/rt:control-plane-protocols, instead of /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol, is that we do not allow multiple instances of MSDP.

Thanks,
- Xufeng

From: Reshad Rahman (rrahman) [mailto:[email-masked]]
Sent: Friday, February 2, 2018 12:08 PM
To: [email-masked]<mailto:[email-masked]>; Xufeng Liu <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mahesh Sivakumar (masivaku) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;  [email-masked]<mailto:[email-masked]>
Subject: Re: Hi all, about the modification of MSDP YANG

Hi Sandy,

I don’t know what warning you are getting now but from a quick look at the revision you sent I see couple of issues.

     identity msdp {
       base "rt:routing-protocol";  <== should be rt:control-plane-protocol
       description "MSDP";
     }
<snip>
     /*
      * Data nodes
      */
     augment "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol" {
        when "rt:type = 'MSDP'" { <== should be "rt:type = 'msdp:msdp'"

HTH,
Reshad.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, February 2, 2018 at 4:37 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>,  "Mahesh Sivakumar (masivaku)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"  <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"  <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>"  <[email-masked]<mailto:[email-masked]>>
Cc: "Reshad Rahman (rrahman)" <[email-masked]<mailto:[email-masked]>>
Subject: FW: Hi all, about the modification of MSDP YANG

Hi all,

I deleted some groupings and make the model more clear.

And I updated the decription of (peer-as, up-time, expire).  Please review it.

A warning is still existing about rt:type:

5, - augment of control-plane-protocols is incorrect. There should be an identity msdp with

base "rt:routing-protocol" and then augment

"/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol" with a when

statement. Take a look at OSPF YANG for an example.

[Sandy]: Added the identity and modify the augmentation, but it seems like there is no MSDP register in rt:type.

How can we register it?

Thanks,

Sandy
原始邮件
发件人：张征00007940
收件人： <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;  <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;徐本崇10065053;  <[email-masked]<mailto:[email-masked]>>; <[email-masked]<mailto:[email-masked]>>;
抄送人： <[email-masked]<mailto:[email-masked]>>;
日 期 ：2018年01月29日  17:04
主 题 ：Hi all, about the modification of MSDP YANG

Hi all,

YANG doctor Reshad had finished the early review about MSDP YANG.

I finished the preliminary modification version, please review it.

I think some advices from Reshad should be discussed:

1, - Not sure why peer-as is needed. Don't see it in RFC3618.

2, - leaf up-time, what's meant by "up time" in the description? Is it time it's

been created?

3, - description for leaf expire seems wrong.

[Sandy]: These items (peer-as, up-time, expire) doesn't existed in RFC3618, are these unnecessary? Please write down your

description if you insist on it. If nobody insist on it, should we delete them?

4, - Groupings are used for data which is used only once. Is this done on purpose or

was the intention to use those groupings more than once?

[Sandy]: These eight groupings are used only once, should we change them to container?

authentication-container;

global-config-attributes;

peer-config-attributes;

peer-state-attributes;

sa-cache-state-attributes;

statistics-container

statistics-error

statistics-queue

5, - augment of control-plane-protocols is incorrect. There should be an identity msdp with

base "rt:routing-protocol" and then augment

"/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol" with a when

statement. Take a look at OSPF YANG for an example.

[Sandy]: Added the identity and modify the augmentation, but it seems like there is no MSDP register in rt:type.

How can we register it?

Most of the suggestion is adopted. The modification detail pls see below:

- Too many features (17)! Every piece of config has an if-feature statement.

Some of the configs (timers?) should be part of most/basic implementations, for

other config (e.g. authentication) I can see why a feature would be used.

[Sandy]: Modified the three timers (connect-retry, hold, keepalive) to fixed format.

-“import ietf-yang-types” should have a reference to RFC6991 (see section 4.7 of

rfc6087bis-15)

- “import ietf-inet-types” should have a reference to RFC6991

- “import ietf-routing” should have a reference to RFC8022

- “import ietf-interfaces” should have a reference to RFC7223

- "import ietf-ip" should have a reference to RFC7277

- "import ietf-key-chain" should have a reference to RFC8177

[Sandy]: Added all the references above.

- organization s/"...PIM( Protocols for IP Multicast ) Working

Group"/"...PIM (Protocols for IP Multicast) Working Group"?

- Remove WG Chairs from contact information as per Appendix C of rfc6087bis-15

- No copyright in the module description, see Appendix of 6087bis-15 for a module description

example

- Module description must contain reference to RFC, see Appendix C of

rfc6087bis-15

[Sandy]: Removed WG chairs and add copyright from Appendix of rfc6087bis. Added reference to RFC3618.

- grouping authentication-container. key-chain and password both

use if-feature peer-key-chain.

[Sandy]: Removed the if-feature peer-key-chain from password.

- grouping connect-source. The name is not very

descriptive. Should this be something along the lines of tcp-connection-source?

[Sandy]: Changed the name "connect-source" to "tcp-connection-source".

- grouping global-state-attributes has nothing

[Sandy]: Deleted the grouping.

- Some of the descriptions are

pretty terse. e.g. for rpf-peer it says "RPF peer.". In a case like this

consider adding more descriptive text or a reference to the proper section in

RFC3618

[Sandy]: Added more description.

- peer-as (Autonomous System Number) is defined as type string, should

be of type as-number in ietf-inet-types?

[Sandy]: Modified to inet types.

- keepalive-interval depends on holdtime-interval.

There should be "if-feature peer-timer-holdtime" under leaf keepalive-interval

or change the must statement to (assuming we keep the 2 features):

  must "(not ../holdtime-interval) or (. > 1 and . < ../holdtime-interval)".

[Sandy]: Modified the features to fixed format.

- leaf up-time: s/sa cache/SA cache/

- leaf peer-learned-from, change description from "The address of peer that we learned

this SA from ." to "The address of the peer that we learned this SA from."

[Sandy]: Modified.

- RPC leaf group, I thought we had a type for IP multicast address? If not, it should be done?

[Sandy]: Yes. Added the rt-type reference to RFC8294.

- s/msdp/MSDP/

- In rpc msdp-clear-peer, s/Clears the session to the peer./Clears

the TCP connection to the peer./

- In rpc msdp-clear-sa-cache, why have the enum '*' for source-addr. Can't the same technique as for peer-address be

used?

- msdp prefix not needed in rpc names

[Sandy]: Done.

- MSDP peers are configured in a mesh-group, did the authors consider adding state per mesh-group, e.g. all the

peers in a particular mesh-group?

[Sandy]: IMO it is unnecessary because the states of peers is not unified in a mesh-group.

General:

- Per Appendix B of rfc6087bis-15: "that all YANG modules containing

imported items are cited as normative reference". So RFCs 6991, 7223,

7277, 8022 and 8177 should be included in the normative reference

section.

[Sandy]: Added.

- Section 3 "the irrelevant information", add a reference/explanation for what

the irrelevant information is. s/the irrelevant information/irrelevant

information/?

[Sandy]: Changed the description.

- Section 5 should give a brief description of what the RPCs do.

[Sandy]: Added some description.

- Section 6 any plans for notifications? If not, just say so.

[Sandy]: Done.

- Need Security

Considerations, see sections 3.7 and 6 of rfc6087bis-15

[Sandy]: Added security consideration section.

- Need IANA Considerations, see section 3.8 of rfc6087bis-15

[Sandy]: Added IANA considerations.

- Need license in YANG module,

see appendix B of rfc6087bis-15

[Sandy]: Added the YANG module description.

Thanks,

Sandy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Feb 2018 09:20:11 +0100 (CET)

Hi,

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> Hi YDs,
> 
> MSDP YANG authors want to enforce single-instance of MSDP
> control-plane protocol. The when “rt:type = ‘msdp’“ allows multiple
> control-pane-protocol instances as long as they have different
> rt:name. The only workaround I thought of is to have a when statement
> on the name in the top level container. This would still multiple
> control-plane-protocol instance of type msdp but restricts the name to
> a fixed name (msdp-protocol in this case) for the top level msdp
> container to exist. Any suggestions on how to do this better?

Hard-coding a name like this is IMO a bad idea.

Better would be to simply state in text that there MUST only be one
instance of this type.

But you can also add a must statement that enforces this:

   augment "/rt:routing/rt:control-plane-protocols/"
         + "rt:control-plane-protocol" {
      when 'derived-from-or-self(rt:type, "msdp:msdp"'  {
     container msdp {
       must 'count(/rt:routing/rt:control-plane-protocols/'
          + '      rt:control-plane-protocol['
          + '        derived-from-or-sel(../rt:type, "msdp:msdp")]) <= 1'";

In general, you should be careful with the usage of "count", since it
will loop through *all* instances in the list every time.  If the list
is big, this can have a performance impact.

Also note that I use derived-from-or-self instead of equality for the
identity.

/martin

> Cc: "[email-masked]" <[email-masked]>, "Mahesh Sivakumar
> (masivaku)" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "Acee Lindem (acee)" <[email-masked]>
> I understand that you want only 1 MSDP instance but I don’t think that
> justifies /rt:routing/rt:control-plane-protocols. If we do that we
> will end up with all single-instance protocols under
> /rt:routing/rt:control-plane-protocols and all the multi-instance ones
> under
> /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol.
> 
> I am not sure what’s the best way to enforce single-instance, I can
> check with the other YDs on this topic. One way it can be done is as
> follows (I’ve added the when statement in bold to existing BFD model),
> it enforces that the protocol name is ‘bfdv1’. So multiple instances
> with rt:type=bfd-types:bfdv1 could be created, but only one of these
> instances can have the bfd container. This is probably not the best
> way but the point is that IMO protocols have to go under
> /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol.
> 
> Regards,
> Reshad.
> 
> Cc: "Reshad Rahman (rrahman)" <[email-masked]>,
> "[email-masked]" <[email-masked]>, "Mahesh Sivakumar
> (masivaku)" <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>, "[email-masked]"
> <[email-masked]>
> In RFC8022bis, the rt:type is defined under
> /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol. If
> we augment /rt:routing/rt:control-plane-protocols, the “when”
> statement will not be valid, because it cannot find the rt:type. I
> don’t think that we need the “when” statement. The container with
> “presence” will serve the purpose of the identity. We can simply take
> out the “when” statement and the definition of the MSDP identity.
> 
> Thanks,
> - Xufeng
> 
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> 收件人： <[email-masked]<mailto:[email-masked]>>;张征00007940;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;徐本崇10065053;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> 日 期 ：2018年02月03日 01:21
> The reason that we used to augment
> /rt:routing/rt:control-plane-protocols, instead of
> /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol, is
> that we do not allow multiple instances of MSDP.
> 
> Thanks,
> - Xufeng
> 
> To: [email-masked]<mailto:[email-masked]>; Xufeng Liu
> <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; Mahesh Sivakumar
> (masivaku) <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>
> I don’t know what warning you are getting now but from a quick look at
> the revision you sent I see couple of issues.
> 
>      identity msdp {
>      augment
>      "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol" {
> From: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> To: "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>, "Mahesh Sivakumar
> (masivaku)" <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>,
> "[email-masked]<mailto:[email-masked]>"
> <[email-masked]<mailto:[email-masked]>>
> Cc: "Reshad Rahman (rrahman)"
> <[email-masked]<mailto:[email-masked]>>
> [Sandy]: Added the identity and modify the augmentation, but it seems
> like there is no MSDP register in rt:type.
> 
> How can we register it?
> 
> 
> 
> Thanks,
> 
> Sandy
> 原始邮件
> 发件人：张征00007940
> 收件人： <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;徐本崇10065053;
> <[email-masked]<mailto:[email-masked]>>;
> <[email-masked]<mailto:[email-masked]>>;
> [Sandy]: These items (peer-as, up-time, expire) doesn't existed in
> RFC3618, are these unnecessary? Please write down your
> 
> [Sandy]: Added the identity and modify the augmentation, but it seems
> like there is no MSDP register in rt:type.
> 
> How can we register it?
> 
> 
> 
> 
> 
> - Too many features (17)! Every piece of config has an if-feature
> - statement.
> 
> -“import ietf-yang-types” should have a reference to RFC6991 (see
> -section 4.7 of
> 
> rfc6087bis-15)
> 
> - Remove WG Chairs from contact information as per Appendix C of
> - rfc6087bis-15
> 
> - No copyright in the module description, see Appendix of 6087bis-15 for
> - a module description
> 
> example
> 
> - leaf peer-learned-from, change description from "The address of peer
> - that we learned
> 
> - RPC leaf group, I thought we had a type for IP multicast address? If
> - not, it should be done?
> 
> - In rpc msdp-clear-sa-cache, why have the enum '*' for
> - source-addr. Can't the same technique as for peer-address be
> 
> 
> 
> used?
> 
> - MSDP peers are configured in a mesh-group, did the authors consider
> - adding state per mesh-group, e.g. all the
> 
> - Section 3 "the irrelevant information", add a reference/explanation
> - for what
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Feb 2018 10:42:11 +0100

> is big, this can have a performance impact.

Instead of count(), it is possible to use the so-called Muenchian method:

    container msdp {
      must "not(../preceding-sibling::rt:control-plane-protocol["
         + "derived-from-or-self(rt:type, 'msdp:msdp')])";
      ..
    }

It basically states that the control-plane-protocol containing the "msdp"
container must not be preceded with a control-plane-protocol entry of the
msdp:msdp type (or derived).

Lada

> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 8 Feb 2018 11:08:53 +0000

Hi Lada,

On 2/8/18, 4:42 AM, "yang-doctors on behalf of Ladislav Lhotka" <[email-masked] on behalf of [email-masked]> wrote:

    
        container msdp {

This looks like an elegant solution. However, since the key for the control-plane-protocol  list is "type name", won't it only work if the previous sibling has a  "name" that is precedes the one being added? 

Thanks,
Acee

    Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Feb 2018 12:34:02 +0100

On Thu, 2018-02-08 at 11:08 +0000, Acee Lindem (acee) wrote:
> Hi Lada,
> 
> On 2/8/18, 4:42 AM, "yang-doctors on behalf of Ladislav Lhotka" <yang-doctors
> [email-masked] on behalf of [email-masked]> wrote:
> 
> This looks like an elegant solution. However, since the key for the control-
> plane-protocol  list is "type name", won't it only work if the previous
> sibling has a  "name" that is precedes the one being added? 

XPath has no notion of YANG list keys, so it should work for "type" only.

Lada 

>     > > <[email-masked]<mailto:[email-masked]>
> >;
>     > > [email-masked]<mailto:[email-masked]
> >;
>     > > <[email-masked]<mailto:[email-masked]>
> >,
>     > > <[email-masked]<mailto:[email-masked]>
> >;

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Feb 2018 12:39:44 +0100 (CET)

"Acee Lindem (acee)" <[email-masked]> wrote:
> This looks like an elegant solution.

"elegant" as in "less obvious" ;)  It has the same time complexity as
the count() solution.

However, since the key for the control-plane-protocol  list is "type
name", won't it only work if the previous sibling has a  "name" that
is precedes the one being added?

For each list entry that has this container, the expression is
evaluated.  It will scan all preceding entries and ensure that there
are none with this type.  So the order of the entries doesn't matter;
if there are two with the same type, one of them has to be before the
other.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Feb 2018 13:02:07 +0100

On Thu, 2018-02-08 at 12:39 +0100, Martin Bjorklund wrote:
> > On 2/8/18, 4:42 AM, "yang-doctors on behalf of Ladislav Lhotka" <yang-docto
> [email-masked] on behalf of [email-masked]> wrote:
> 
> > 
> 

It should be faster on the average - it has to scan only preceding siblings of
the MSDP protocol instance whereas count() always has to check *all* protocol
instances.

It is true though that in XSLT this technique can be made considerably more
efficient by using indexed keys.

Lada

> >     > > To: Xufeng Liu <[email-masked]>, "[email-masked]"
> 
> >     > > <[email-masked]>
> 
> >     > > [email-masked]<mailto:[email-masked]
> >;
> 
> >     > > And I updated the decription of (peer-as, up-time, expire).  Please
> 
> >     > > review it.
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 5, - augment of control-plane-protocols is incorrect. There should
> be
> 
> >     > > an identity msdp with
> 
> >     > > 
> 
> >     > > "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol"
> 
> >     > > with a when
> 
> >     > > 
> 
> >     > > 2, - leaf up-time, what's meant by "up time" in the description? Is
> it
> 
> >     > > time it's
> 
> >     > > 
> 
> >     > > been created?
> 
> >     > > 
> 
> >     > > description if you insist on it. If nobody insist on it, should we
> 
> >     > > delete them?
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 4, - Groupings are used for data which is used only once. Is this
> done
> 
> >     > > on purpose or
> 
> >     > > 
> 
> >     > > [Sandy]: These eight groupings are used only once, should we change
> 
> >     > > them to container?
> 
> >     > > 
> 
> >     > > 5, - augment of control-plane-protocols is incorrect. There should
> be
> 
> >     > > an identity msdp with
> 
> >     > > 
> 
> >     > > "/rt:routing/rt:control-plane-protocols/rt:control-plane-protocol"
> 
> >     > > with a when
> 
> >     > > 
> 
> >     > > Most of the suggestion is adopted. The modification detail pls see
> 
> >     > > below:
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 
> 
> >     > > Some of the configs (timers?) should be part of most/basic
> 
> >     > > implementations, for
> 
> >     > > 
> 
> >     > > other config (e.g. authentication) I can see why a feature would be
> 
> >     > > used.
> 
> >     > > 
> 
> >     > > [Sandy]: Modified the three timers (connect-retry, hold, keepalive)
> to
> 
> >     > > fixed format.
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 
> 
> >     > > [Sandy]: Removed WG chairs and add copyright from Appendix of
> 
> >     > > rfc6087bis. Added reference to RFC3618.
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 
> 
> >     > > descriptive. Should this be something along the lines of
> 
> >     > > tcp-connection-source?
> 
> >     > > 
> 
> >     > > pretty terse. e.g. for rpf-peer it says "RPF peer.". In a case like
> 
> >     > > this
> 
> >     > > 
> 
> >     > > consider adding more descriptive text or a reference to the proper
> 
> >     > > section in
> 
> >     > > 
> 
> >     > > RFC3618
> 
> >     > > 
> 
> >     > > There should be "if-feature peer-timer-holdtime" under leaf
> 
> >     > > keepalive-interval
> 
> >     > > 
> 
> >     > >   must "(not ../holdtime-interval) or (. > 1 and . <
> 
> >     > >   ../holdtime-interval)".
> 
> >     > > 
> 
> >     > > this SA from ." to "The address of the peer that we learned this SA
> 
> >     > > from."
> 
> >     > > 
> 
> >     > > [Sandy]: Modified.
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 
> 
> >     > > [Sandy]: IMO it is unnecessary because the states of peers is not
> 
> >     > > unified in a mesh-group.
> 
> >     > > 
> 
> >     > > 
> 
> >     > > 
> 
> >     > > General:
> 
> >     > > 
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 8 Feb 2018 14:41:02 +0000

Thanks for the suggestions. I agree that hard-coding the name is a bad idea, glad that a cleaner way of doing this is possible. 
- We can move the must statement up to restrict max of 1 control-plane-protocol instance of type msdp?
- Acee/Lada, should a note be added to section 5.3 of 8022bis regarding how to enforce single instance? How much of a concern is the performance impact in this specific case?

Regards,
Reshad.
 
On 2018-02-08, 7:02 AM, "Ladislav Lhotka" <[email-masked]> wrote:

    
    
    Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Feb 2018 15:47:04 +0100 (CET)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> Thanks for the suggestions. I agree that hard-coding the name is a
> bad idea, glad that a cleaner way of doing this is possible.
> - We can move the must statement up to restrict max of 1
>   control-plane-protocol instance of type msdp?

That's what the current must statement does.  You can't have the
must stmt directly in the augment.

> - Acee/Lada, should a note be added to section 5.3 of 8022bis
>   regarding how to enforce single instance? How much of a concern is
>   the performance impact in this specific case?

All must expressions are conceptual.  This means that an implementator
that thinks that a particular must statement has performance issues
can implement the same logic in a better way.

(this is of course not a reason to write sloppy and slow expressions;
but I think both alternatives presented are ok).

/martin

---

From: Xufeng Liu <[email-masked]>
Date: Thu, 8 Feb 2018 14:48:08 +0000

Hi All,

I feel that such a solution is still not clean enough to outweigh the simple augmentation to "/rt:routing/rt:control-plane-protocols/". 

Some considerations are:

- Name management: Neither the operator nor the implementation wants to deal with the artificial name, whether it is hardcoded, user-configured, or system-generated. When we implement such singleton protocol, we don't save a name anywhere.
- The complexity of validation: The "when" statement is an unnecessary expense to the user and to the implementation, especially if we need to check all instances.
- Data tree query: If the singleton "MSDP" is mixed with other protocol instances, it is less obvious or harder to search for. Depending on the implementation, it would be worse if the entire list needs to be iterated. 
- Tree hierarchy  organization: I don't see too big a problem with "all single-instance protocols under /rt:routing/rt:control-plane-protocols and all the multi-instance ones under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol". If necessary, some of the names can be adjusted. 

Thanks,
- Xufeng

> -----Original Message-----
> Sent: Thursday, February 8, 2018 9:41 AM
> To: Ladislav Lhotka <[email-masked]>; Martin Bjorklund <[email-masked]>;
> Acee Lindem (acee) <[email-masked]>
> Cc: [email-masked]; [email-masked]; Xufeng Liu
> <[email-masked]>
> Subject: Re: [yang-doctors] How to restrict to have single control-plane-
> protocol instance
> 
> Thanks for the suggestions. I agree that hard-coding the name is a bad idea,
> glad that a cleaner way of doing this is possible.
> - Acee/Lada, should a note be added to section 5.3 of 8022bis regarding how
> to enforce single instance? How much of a concern is the performance
> impact in this specific case?
> 
> Regards,
> Reshad.
> 
>     > >     > > control-plane-protocol instance of type msdp but restricts the
> name
>     > to
>     >
>     > >     container must not be preceded with a control-plane-protocol entry
> of
>     > the
>     >
> If
>     > >     > > 发件人：
>     > >     > > <tanmoy.kundu@alcatel-
> lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
>     > com>>;
>     >
>     > >     > > To: [email-masked]<mailto:[email-masked]>;
> Xufeng
>     > Liu
>     >
>     > >     > > (masivaku)
>     > >     > > tanmoy.kundu@alcatel-
> lucent.com<mailto:[email-masked]
>     > om>;
>     >
>     > >     > > I don’t know what warning you are getting now but from a quick
> look
>     > at
>     >
>     > >     > > From:
> "[email-masked]<mailto:[email-masked]>"
>     >
>     > >     > > (masivaku)"
> <[email-masked]<mailto:[email-masked]>>,
>     >
>     > >     > > "tanmoy.kundu@alcatel-
> lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
>     > com>"
>     >
>     > >     > > <tanmoy.kundu@alcatel-
> lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
>     > com>>,
>     >
>     > >     > > <tanmoy.kundu@alcatel-
> lucent.com<mailto:tanmoy.kundu@alcatel-lucent.
>     > com>>;
>     >
>     > >     > > - No copyright in the module description, see Appendix of
> 6087bis-15
>     > for
>     >
>     > >     > > - a module description
>     >
>     > >     > >
>     >
>     > >     > > example
>     >
>     > >     > >
>     >
>     > >     > > - Module description must contain reference to RFC, see
> Appendix C
>     > of
>     >
>     > >     > >
>     >
>     > >     > > rfc6087bis-15
>     >
>     > >     > >
>     >
>     > >     > > - leaf peer-learned-from, change description from "The address
> of
>     > peer
>     >
>     > >     > > - that we learned
>     >
>     > >     > >
>     >

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 15 Feb 2018 13:39:32 +0000

Hi Xufeng,

I think the intent of 8022bis was to have all protocols under /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol. I agree that forcing a name for a single-instance is cumbersome, but I think it is too late to change tree hierachy organization at this point.

I will defer to other YDs and 8022bis authors on this.

Regards,
Reshad.

On 2018-02-08, 9:48 AM, "Xufeng Liu" <[email-masked]> wrote:

    Hi All,

    Some considerations are:

    Thanks,
    - Xufeng

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 16 Feb 2018 23:09:43 +0000

All, 

As seems to be the modus operandi for YANG issues, we have 3 separate opinions as to how a protocol only supporting a single instance should be realized. 

  1. Augment the existing control plane protocols list (RFC 8022BIS) and specify in the description text that only a single instance is supported. 
  2. Augment the existing control plane protocols list (RFC 8022BIS) and use a YANG 1.1 must() restriction as discussed by Martin and Lada. 
  3. Augment the container one level up from the list for singleton protocols (suggested by Xufeng). 

Other than the simplicity of option #1, I'm not sure I fully appreciate the pros and cons of #2 and #3. For #3, one determent would be that the control plane protocols are in a location other than where they were originally envisioned and I don't relish pulling RFC8022BIS off the RFC queue to document.  

Thanks,
Acee

On 2/15/18, 8:39 AM, "Reshad Rahman (rrahman)" <[email-masked]> wrote:

    Hi Xufeng,

    
    Regards,
    Reshad.

        Hi All,

        Some considerations are:

        Thanks,
        - Xufeng

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Feb 2018 10:13:46 +0100 (CET)

Hi,

"Acee Lindem (acee)" <[email-masked]> wrote:
>   1. Augment the existing control plane protocols list (RFC 8022BIS)
>   and specify in the description text that only a single instance is
>   supported.
>   2. Augment the existing control plane protocols list (RFC 8022BIS)
>   and use a YANG 1.1 must() restriction as discussed by Martin and
>   Lada.

With options #1 and #2, if you need a reference to a control plane
protocol, you can always have a leafref to the well-known single list
of protocols.  With option #3, you need a leafref to either a protocol
in this list, or some of the singletons (if you know where to find
them).

There's a similiar issue with augments; if you want to augment some
generic additional data to all control-plane protocols, you can
augment a single list with option #1 and #2.  With option #3 you'd
have to explicitly augment all singletons as well.  This is not very
scalable.

> Other than the simplicity of option #1, I'm not sure I fully
> appreciate the pros and cons of #2

#2 is really just a more formal version of #1.  There is a constraint
and it is either formally defined with XPath, or just defined in text.

But I think there was also a proposal to require the single instance
to have a well-known name - but maybe this proposal is no longer on
the table.

/martin

> and #3. For #3, one determent would be that the control plane protocols are in a location other than where they were originally envisioned and I don't relish pulling RFC8022BIS off the RFC queue to document.  
> 
> Thanks,
> Acee
>

---

From: Christian Hopps <[email-masked]>
Date: Mon, 19 Feb 2018 05:01:55 -0500

> to have a well-known name - but maybe this proposal is no longer on

I actually liked this solution; however, instead of picking an arbitrary "well-known" value for name, I would specify the 0 length string instead. I think that reinforces the idea that this isn't actually a named instance. :)

   augment "/rt:routing/rt:control-plane-protocols/"
         + "rt:control-plane-protocol" {
      when "derived-from-or-self(rt:type, 'msdp:msdp') and rt:name = ''"  {
      container msdp {

Thanks,
Chris.

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 19 Feb 2018 14:36:04 +0000

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Monday, February 19, 2018 4:14 AM
> To: [email-masked]
> Cc: [email-masked]; Xufeng Liu <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> > As seems to be the modus operandi for YANG issues, we have 3 separate
> opinions as to how a protocol only supporting a single instance should be
> realized.
> >

[Xufeng] Such a common augmentation and reference are not anticipated. Is there such a use case? Each protocol is designed and structured too differently to require or fit a common augmentation. Such "singleton" protocols are designed to be managed by simple "enable" or "disable" operations, without using the concept of instantiation. The instance name does not exist in the implementation. An analogy is to "enable IPv4 or IPv6 on an interface", which we do not model as "create an IPv6 instance with a well-known instance name, on an interface.".

Thanks,
- Xufeng

> > and #3. For #3, one determent would be that the control plane protocols
> are in a location other than where they were originally envisioned and I don't
> relish pulling RFC8022BIS off the RFC queue to document.
> >
> > Thanks,
> > Acee
> >
> >     I think the intent of 8022bis was to have all protocols under
> /rt:routing/rt:control-plane-protocols/rt:control-plane-protocol. I agree that
> forcing a name for a single-instance is cumbersome, but I think it is too late
> to change tree hierachy organization at this point.
> >
> >         I feel that such a solution is still not clean enough to outweigh the
> simple augmentation to "/rt:routing/rt:control-plane-protocols/".
> >
> >         Some considerations are:
> >
> >         - Name management: Neither the operator nor the implementation
> wants to deal with the artificial name, whether it is hardcoded, user-
> configured, or system-generated. When we implement such singleton
> protocol, we don't save a name anywhere.
> >         - The complexity of validation: The "when" statement is an
> unnecessary expense to the user and to the implementation, especially if we
> need to check all instances.
> >         - Data tree query: If the singleton "MSDP" is mixed with other protocol
> instances, it is less obvious or harder to search for. Depending on the
> implementation, it would be worse if the entire list needs to be iterated.
> >         - Tree hierarchy  organization: I don't see too big a problem with "all
> single-instance protocols under /rt:routing/rt:control-plane-protocols and all
> the multi-instance ones under /rt:routing/rt:control-plane-
> protocols/rt:control-plane-protocol". If necessary, some of the names can be
> adjusted.
> >
> >         Thanks,
> >         - Xufeng
> >
> >
> bad idea,
> >         > - We can move the must statement up to restrict max of 1 control-
> plane-
> >         > protocol instance of type msdp?
> regarding how
> >         >     > > On 2/8/18, 4:42 AM, "yang-doctors on behalf of Ladislav
> Lhotka"
> >         > <yang-docto
> >         >     > >     > > control-plane protocol. The when “rt:type =
> ‘msdp’“ allows
> >         > multiple
> >         >     >
> >         >     > >     > > rt:name. The only workaround I thought of is to have a
> when
> >         >     > statement
> >         >     >
> >         >     > >     >           + '        derived-from-or-sel(../rt:type, "msdp:msdp")])
> <=
> >         >     > 1'";
> >         >     >
> >         >     > >     >
> >         >     >
> >         >     > >     >
> >         >     >
> >         >     > >     Instead of count(), it is possible to use the so-called
> Muenchian
> >         >     > method:
> >         >     >
> >         >     > >
> >         >     >
> >         >     > >         container msdp {
> >         >     >
> >         >     > >     It basically states that the control-plane-protocol containing
> the
> >         >     > "msdp"
> >         >     >
> >         >     the MSDP protocol instance whereas count() always has to check
> *all*
> >         > protocol
> >         >     instances.
> >         >
> >         >     It is true though that in XSLT this technique can be made
> considerably
> >         > more
> >         >     > >     > > Cc: "[email-masked]" <[email-masked]>,
> "Mahesh
> >         > Sivakumar
> >         >     >
> >         >     > >     > > I understand that you want only 1 MSDP instance but I
> don’t think
> >         >     > that
> >         >     >
> >         >     > >     > > /rt:routing/rt:control-plane-protocols and all the multi-
> instance
> >         >     > ones
> >         >     >
> >         >     > >     > > under
> >         >     >
> >         >     > >     > > check with the other YDs on this topic. One way it can be
> done is
> >         > as
> >         >     >
> >         >     > >     > > follows (I’ve added the when statement in bold to existing
> BFD
> >         >     > model),
> >         >     >
> >         >     > >     > > with rt:type=bfd-types:bfdv1 could be created, but only
> one of
> >         > these
> >         >     >
> >         >     > >     > > instances can have the bfd container. This is probably not
> the
> >         > best
> >         >     >
> >         >     > >     > > "[email-masked]" <[email-masked]>,
> "Mahesh
> >         > Sivakumar
> >         >     >
> >         >     > >     > > don’t think that we need the “when” statement. The
> container
> >         > with
> >         >     >
> >         >     > >     > > “presence” will serve the purpose of the identity. We can
> simply
> >         >     > take
> >         >     >
> >         >     > >     > > 收件人：
> <[email-masked]<mailto:[email-masked]>>;
> >         > 张征00007940;
> >         >     >
> >         >     > >     > > /rt:routing/rt:control-plane-protocols/rt:control-plane-
> protocol,
> >         > is
> >         >     >
> >         >     > >     > > To:
> [email-masked]<mailto:[email-masked]>;
> >         > Xufeng
> >         >     > Liu
> >         >     >
> >         >     > >     > > [email-masked]<mailto:[email-masked]>;
> Mahesh
> >         > Sivakumar
> >         >     >
> >         >     > >     > > (masivaku)
> >         >     > >     > >        base "rt:routing-protocol";  <== should be rt:control-
> plane-
> >         >     > protocol
> >         >     >
> >         >     > >     > >        description "MSDP";
> >         >     >
> >         >     > >     > >      }
> >         >     >
> >         >     > >     > > <snip>
> >         >     >
> >         >     > >     > >      /*
> >         >     >
> >         >     > >     > >       * Data nodes
> >         >     >
> >         >     > >     > >       */
> >         >     >
> >         >     > >     > >      augment
> >         >     >
> >         >     > >     > >      "/rt:routing/rt:control-plane-protocols/rt:control-
> plane-
> >         >     > protocol" {
> >         >     >
> >         >     > >     > > To:
> "[email-masked]<mailto:[email-masked]>"
> >         >     >
> >         >     > >     > > <[email-masked]<mailto:[email-masked]>>,
> "Mahesh
> >         >     > Sivakumar
> >         >     >
> >         >     > >     > > (masivaku)"
> >         >     > >     > > [Sandy]: Added the identity and modify the augmentation,
> but it
> >         >     > seems
> >         >     >
> >         >     > >     > > 收件人：
> <[email-masked]<mailto:[email-masked]>>;
> >         >     >
> >         >     > >     > > 抄送人：
> <[email-masked]<mailto:[email-masked]>>;
> >         >     >
> >         >     > >     > > 日 期 ：2018年01月29日  17:04
> >         >     >
> >         >     > >     > > YANG doctor Reshad had finished the early review about
> MSDP
> >         > YANG.
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > [Sandy]: These eight groupings are used only once, should
> we
> >         > change
> >         >     >
> >         >     > >     > > them to container?
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > [Sandy]: Added the identity and modify the augmentation,
> but it
> >         >     > seems
> >         >     >
> >         >     > >     > > other config (e.g. authentication) I can see why a feature
> would
> >         > be
> >         >     >
> >         >     > >     > > used.
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > -“import ietf-yang-types” should have a reference to
> RFC6991
> >         > (see
> >         >     >
> >         >     > >     > > -section 4.7 of
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > rfc6087bis-15)
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > - Remove WG Chairs from contact information as per
> Appendix C
> >         > of
> >         >     >
> >         >     > >     > > - rfc6087bis-15
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > - grouping authentication-container. key-chain and
> password
> >         > both
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > [Sandy]: Changed the name "connect-source" to "tcp-
> connection-
> >         >     > source".
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > consider adding more descriptive text or a reference to
> the
> >         > proper
> >         >     >
> >         >     > >     > > section in
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > RFC3618
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > - peer-as (Autonomous System Number) is defined as
> type string,
> >         >     > should
> >         >     >
> >         >     > >     > >
> >         >     >
> >         >     > >     > > - RPC leaf group, I thought we had a type for IP multicast
> address?
> >         >     > If
> >         >     >
> >         >     > >     > > - MSDP peers are configured in a mesh-group, did the
> authors
> >         >     > consider
> >         >     >
> >         >     > >     > > imported items are cited as normative reference". So
> RFCs 6991,
> >         >     > 7223,
> >         >     >
> >         >     > >     > >
> >         >     >

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 19 Feb 2018 17:09:15 +0000

Hi Xufeng, 
See inline. 

On 2/19/18, 9:36 AM, "Xufeng Liu" <[email-masked]> wrote:

    

What about redistribution of information (routes or other) between control plane protocols? My view is that we have a number of options that would not close the door on the type of references Martin has posited. 

Thanks,
Acee

    Thanks,
    - Xufeng
    
    > protocol.
    > protocol.
    > protocol.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 19 Feb 2018 18:35:23 +0000

On 2/19/18, 5:02 AM, "Christian Hopps" <[email-masked]> wrote:

    

One benefit of this solution is that it solves Xufeng's issue of what the client uses as the instance name. 

    Thanks,
    Chris.

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 19 Feb 2018 18:48:00 +0000

Should we consider having an empty name i.e. ""?

Martin said:
    But I think there was also a proposal to require the single instance     to have a well-known name - but maybe this proposal is no longer on     the table.

On 2018-02-19, 4:13 AM, "Martin Bjorklund" <[email-masked]> wrote:

    Hi,

    

    

    /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 19 Feb 2018 20:02:04 +0100 (CET)

"Acee Lindem (acee)" <[email-masked]> wrote:
>     >> opinions as to how a protocol only supporting a single instance should
>     >> be realized.
>     >>
>     I actually liked this solution; however, instead of picking an
>     arbitrary "well-known" value for name, I would specify the 0 length
>     string instead. I think that reinforces the idea that this isn't
>     actually a named instance. :)
>     

Note that with options #1 and #2, the client is of course free to send
the name "".  But the client isn't *restricted* to "" - it can use
whatever meaningful name it wants.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 19 Feb 2018 20:01:21 +0000

+1

On 2018-02-19, 1:35 PM, "yang-doctors on behalf of Acee Lindem (acee)" <[email-masked] on behalf of [email-masked]> wrote:

        

        

        Thanks,
        Chris.

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 20 Feb 2018 14:29:02 +0000

Using "" as the name is better, but I am not sure that it is good enough. When we use ConfD to translate the model to a command line, if the option "tailf:cli-expose-key-name" is not used, we will have:

edit routing control-plane-protocols control-plane-protocol type msdp name ''"

If the option "tailf:cli-expose-key-name" is used, we will have:

edit routing control-plane-protocols control-plane-protocol msdp ''"

I am pretty sure that we would get a bug report on this, asking what is the purpose to have: name ''", and requesting a suppression on the term, but we do not have a good way to achieve.

As a comparison, the option #3 will give:

edit routing control-plane-protocols msdp

This is the only acceptable solution so far. When a model is not usable by the end-user, other considerations (such as augmentation convenience) will not matter.

Thanks,
- Xufeng

> From: Acee Lindem (acee) [mailto:[email-masked]]
> Sent: Monday, February 19, 2018 1:35 PM
> To: Christian Hopps <[email-masked]>; Martin Bjorklund <[email-masked]>
> Cc: Xufeng Liu <[email-masked]>; [email-masked]; yang-
> [email-masked]
>     I actually liked this solution; however, instead of picking an arbitrary "well-
> known" value for name, I would specify the 0 length string instead. I think that
> reinforces the idea that this isn't actually a named instance. :)
> 
> forcing a name for a single-instance is cumbersome, but I think it is too late to
> change tree hierachy organization at this point.
>     >>
> wants to deal with the artificial name, whether it is hardcoded, user-configured,
> or system-generated. When we implement such singleton protocol, we don't
> save a name anywhere.
> the multi-instance ones under /rt:routing/rt:control-plane-protocols/rt:control-
> plane-protocol". If necessary, some of the names can be adjusted.
>     >>
>     >>         Thanks,
>     >>         - Xufeng
>     >>
>     >>
>     >>         >     > >     > > follows (I’ve added the when statement in bold to
> existing BFD
>     >>         >     > model),
>     >>         >     >
>     >>         >     > >     > > [Sandy]: These eight groupings are used only once,
> should we
>     >>         > change
>     >>         >     >
>     >>         >     > >     > > them to container?
>     >>         >     >
>     >>         >     > >     > >
>     >>         >     >
>     >>         >     > >     > > or change the must statement to (assuming we keep the
> 2
>     >>         > features):
>     >>         >     >
>     >>         >     > >     > >
>     >>         >     >
>     >>         >     > >     > > - Per Appendix B of rfc6087bis-15: "that all YANG
> modules
>     >>         > containing
>     >>         >     >
>     >>         >     > >     > >
>     >>         >     >

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 20 Feb 2018 15:43:57 +0100

On Tue, 2018-02-20 at 14:29 +0000, Xufeng Liu wrote:
> Using "" as the name is better, but I am not sure that it is good enough. When
> we use ConfD to translate the model to a command line, if the option
> "tailf:cli-expose-key-name" is not used, we will have:
> 
> I am pretty sure that we would get a bug report on this, asking what is the
> purpose to have: name ''", and requesting a suppression on the term, but we do
> not have a good way to achieve.

I agree with Chris, the empty string is preferable to inventing a magical name.
The ietf-routing module permits the "name" key to be empty, so implementations
should not choke on it.

Lada

> This is the only acceptable solution so far. When a model is not usable by the
> end-user, other considerations (such as augmentation convenience) will not
> matter.
> 
> Thanks,
> - Xufeng
> 
> > One benefit of this solution is that it solves Xufeng's issue of what the
> > client uses
> > as the instance name.
> > 
> > 
> >     Thanks,
> >     Chris.
> > 
> >     >
> >     >
> >     > /martin
> >     >
> >     >
> > configured,
> > protocols/rt:control-
> >     >>         > To: Ladislav Lhotka <[email-masked]>; Martin Bjorklund <mbj@
> > tail-
> > f.com>;
> >     >>         > Subject: Re: [yang-doctors] How to restrict to have single
> > control-
> > plane-
> >     >>         > protocol instance
> >     >>         >
> > control-
> >     >>         >     > >     > > MSDP YANG authors want to enforce single-
> > instance of
> > MSDP
> >     >>         >     >
> >     >>         >     > >     > > control-pane-protocol instances as long as
> > they have
> > different
> >     >>         >     >
> >     >>         >     > >     > > on the name in the top level container.
> > This would still
> > multiple
> >     >>         >     >
> >     >>         >     > >     > > control-plane-protocol instance of type
> > msdp but
> > restricts the
> >     >>         > name
> >     >>         >     > to
> >     >>         >     >
> >     >>         >     > >     > > a fixed name (msdp-protocol in this case)
> > for the top level
> > msdp
> >     >>         >     >
> >     >>         >     > >     > > container to exist. Any suggestions on how
> > to do this
> > better?
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     > Better would be to simply state in text that
> > there MUST
> > only be one
> >     >>         >     >
> >     >>         >     > >     > instance of this type.
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     > In general, you should be careful with the
> > usage of "count",
> > since it
> >     >>         >     >
> >     >>         >     > >     > will loop through *all* instances in the list
> > every time.  If
> > the list
> >     >>         >     >
> >     >>         >     > >           must "not(../preceding-
> > sibling::rt:control-plane-
> > protocol["
> >     >>         >     >
> >     >>         >     > >     container must not be preceded with a control-
> > plane-
> > protocol entry
> >     >>         > of
> >     >>         >     > the
> >     >>         >     >
> >     >>         >     > "elegant" as in "less obvious" ;)  It has the same
> > time complexity
> > as
> >     >>         >     > the count() solution.
> >     >>         >
> >     >>         >     It should be faster on the average - it has to scan
> > only preceding
> > siblings of
> >     >>         >     > However, since the key for the control-plane-
> > protocol  list is
> > "type
> >     >>         >     > name", won't it only work if the previous sibling has
> > a  "name"
> > that
> >     >>         >     > are none with this type.  So the order of the entries
> > doesn't
> > matter;
> >     >>         >     > if there are two with the same type, one of them has
> > to be
> > before the
> >     >>         >     > other.
> >     >>         >     >
> >     >>         >     >
> >     >>         >     > /martin
> >     >>         >     >
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     > > Thanks,
> >     >>         >     >
> >     >>         >     > > Acee
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     > >     Lada
> >     >>         >     >
> >     >>         >     > >
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     > Also note that I use derived-from-or-self
> > instead of equality
> > for the
> >     >>         >     >
> >     >>         >     > >     > identity.
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     > /martin
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Regards,
> >     >>         >     >
> >     >>         >     > >     > > Reshad.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>, "tanmoy.kundu@alc
> > atel-
> >     >>         > lucent.com"
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>, "Acee Lindem
> > (acee)"
> >     >>         > <[email-masked]>
> >     >>         >     >
> >     >>         >     > >     > > justifies /rt:routing/rt:control-plane-
> > protocols. If we do
> > that we
> >     >>         >     >
> >     >>         >     > >     > > I am not sure what’s the best way to
> > enforce single-
> > instance, I can
> >     >>         >     >
> >     >>         >     > >     > > it enforces that the protocol name is
> > ‘bfdv1’. So multiple
> >     >>         > instances
> >     >>         >     >
> >     >>         >     > >     > >         "This augmentation is only valid
> > for a control-plane
> >     >>         >     > protocol
> >     >>         >     >
> >     >>         >     > >     > >           "This augmentation is only valid
> > for a control-plane
> >     >>         >     > protocol
> >     >>         >     >
> >     >>         >     > >     > >            instance of BFD (type
> > 'bfdv1').";
> >     >>         >     >
> >     >>         >     > >     > >       }
> >     >>         >     >
> >     >>         >     > >     > > <[email-masked]>, "tanmoy.kundu@alc
> > atel-
> >     >>         > lucent.com"
> >     >>         >     >
> >     >>         >     > >     > > we augment /rt:routing/rt:control-plane-
> > protocols, the
> > “when”
> >     >>         >     >
> >     >>         >     > >     > > statement will not be valid, because it
> > cannot find the
> > rt:type. I
> >     >>         >     >
> >     >>         >     > >     > > out the “when” statement and the definition
> > of the MSDP
> > identity.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Thanks,
> >     >>         >     >
> >     >>         >     > >     > > - Xufeng
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Cc: [email-masked]; [email-masked]
> > ;
> >     >>         > [email-masked];
> >     >>         >     >
> >     >>         >     > >     > > [email-masked];
> >     >>         >     > >     > > I am sorry for forgetting the point. I
> > updated the YANG
> > model.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > If no one has comments on it I'd like to
> > submit the new
> > version. :-)
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Thanks,
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Sandy
> >     >>         >     >
> >     >>         >     > >     > > 原始邮件
> >     >>         >     >
> >     >>         >     > >     > > 发件人：
> >     >>         >     > >     > > I don’t know what warning you are getting
> > now but from
> > a quick
> >     >>         > look
> >     >>         >     > at
> >     >>         >     >
> >     >>         >     > >     > >         when "rt:type = 'MSDP'" { <==
> > should be "rt:type =
> >     >>         >     > 'msdp:msdp'"
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > HTH,
> >     >>         >     >
> >     >>         >     > >     > > Reshad.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > From:
> >     >>         >     > >     > > <[email-masked]<mailto:[email-masked]
> > >>
> >     >>         >     >
> >     >>         >     > >     > > And I updated the decription of (peer-as,
> > up-time, expire).
> > Please
> >     >>         >     >
> >     >>         >     > >     > > review it.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > 5, - augment of control-plane-protocols is
> > incorrect.
> > There should
> >     >>         >     > be
> >     >>         >     >
> >     >>         >     > >     > > an identity msdp with
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > "/rt:routing/rt:control-plane-
> > protocols/rt:control-plane-
> > protocol"
> >     >>         >     >
> >     >>         >     > >     > > with a when
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > I finished the preliminary modification
> > version, please
> > review it.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > 1, - Not sure why peer-as is needed. Don't
> > see it in
> > RFC3618.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > 2, - leaf up-time, what's meant by "up
> > time" in the
> > description? Is
> >     >>         >     > it
> >     >>         >     >
> >     >>         >     > >     > > time it's
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > been created?
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > [Sandy]: These items (peer-as, up-time,
> > expire) doesn't
> > existed in
> >     >>         >     >
> >     >>         >     > >     > > description if you insist on it. If nobody
> > insist on it, should
> > we
> >     >>         >     >
> >     >>         >     > >     > > delete them?
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > 4, - Groupings are used for data which is
> > used only once.
> > Is this
> >     >>         >     > done
> >     >>         >     >
> >     >>         >     > >     > > on purpose or
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > 5, - augment of control-plane-protocols is
> > incorrect.
> > There should
> >     >>         >     > be
> >     >>         >     >
> >     >>         >     > >     > > an identity msdp with
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > "/rt:routing/rt:control-plane-
> > protocols/rt:control-plane-
> > protocol"
> >     >>         >     >
> >     >>         >     > >     > > with a when
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Most of the suggestion is adopted. The
> > modification
> > detail pls see
> >     >>         >     >
> >     >>         >     > >     > > below:
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - Too many features (17)! Every piece of
> > config has an if-
> > feature
> >     >>         >     >
> >     >>         >     > >     > > - statement.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Some of the configs (timers?) should be
> > part of
> > most/basic
> >     >>         >     >
> >     >>         >     > >     > > implementations, for
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > [Sandy]: Modified the three timers
> > (connect-retry, hold,
> > keepalive)
> >     >>         >     > to
> >     >>         >     >
> >     >>         >     > >     > > fixed format.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - “import ietf-inet-types” should have a
> > reference to
> > RFC6991
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - “import ietf-routing” should have a
> > reference to
> > RFC8022
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - “import ietf-interfaces” should have a
> > reference to
> > RFC7223
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - "import ietf-key-chain" should have a
> > reference to
> > RFC8177
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - organization s/"...PIM( Protocols for IP
> > Multicast )
> > Working
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > Group"/"...PIM (Protocols for IP Multicast)
> > Working
> > Group"?
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > [Sandy]: Removed WG chairs and add
> > copyright from
> > Appendix of
> >     >>         >     >
> >     >>         >     > >     > > [Sandy]: Removed the if-feature peer-key-
> > chain from
> > password.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > pretty terse. e.g. for rpf-peer it says
> > "RPF peer.". In a case
> > like
> >     >>         >     >
> >     >>         >     > >     > > this
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > There should be "if-feature peer-timer-
> > holdtime" under
> > leaf
> >     >>         >     >
> >     >>         >     > >     > > keepalive-interval
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - leaf peer-learned-from, change
> > description from "The
> > address
> >     >>         > of
> >     >>         >     > peer
> >     >>         >     >
> >     >>         >     > >     > > - that we learned
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > this SA from ." to "The address of the peer
> > that we
> > learned this SA
> >     >>         >     >
> >     >>         >     > >     > > from."
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > [Sandy]: Modified.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - In rpc msdp-clear-peer, s/Clears the
> > session to the
> > peer./Clears
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - source-addr. Can't the same technique as
> > for peer-
> > address be
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > used?
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > [Sandy]: IMO it is unnecessary because the
> > states of
> > peers is not
> >     >>         >     >
> >     >>         >     > >     > > unified in a mesh-group.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > General:
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > 7277, 8022 and 8177 should be included in
> > the normative
> >     >>         > reference
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > section.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > [Sandy]: Added.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - Section 3 "the irrelevant information",
> > add a
> >     >>         >     > reference/explanation
> >     >>         >     >
> >     >>         >     > >     > > - for what
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > the irrelevant information is. s/the
> > irrelevant
> >     >>         >     > information/irrelevant
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > information/?
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - Section 5 should give a brief description
> > of what the
> > RPCs do.
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >
> >     >>         >     > >     > > - Need IANA Considerations, see section 3.8
> > of
> > rfc6087bis-15
> >     >>         >     >
> >     >>         >     > >     > >
> >     >>         >     >