Re: [Rtg-yang-coord] comment concerning draft-shaikh-rtgwg-policy-model-00

["Acee Lindem (acee)" <[e-mail]>]

On May 27, 2015, at 12:47 PM, Acee Lindem (acee) <[e-mail]<mailto:[e-mail]>> wrote:

Hi Anees,
I had noted problems with the prefix-lists in the draft as well but hadn’t got around to raising them. One thing about the masklength and masklength-range is that there is no validation in the model snippet below. In other words, there is nothing to express that the masklength must between 0..32 for IPv4 addresses and 0..128 for IPv6 addresses  (this is enforced by the ip-prefix type from RFC 6991). Similarly, as a string there in no inherent validation of the masklength-range (e.g., both values must be >= masklength, second value must be >= first-value, and both values must be >= AF specific limit).

Of course I meant "<= AF specific limit”.

Thanks,
Acee


Also, there is nothing to prevent one from mixing IPv4 and IPv6 prefixes in the same length which is definitely not allowed for the prefix-lists we all know and love.
Thanks,
Acee

From: Anees Shaikh <[e-mail]<mailto:[e-mail]>>
Date: Wednesday, May 27, 2015 at 12:09 PM
To: Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>>, Routing YANG <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Rtg-yang-coord] comment concerning draft-shaikh-rtgwg-policy-model-00

Juergen, you're right that prefix-lists in the model turned out to be a bit problematic as currently defined.  We've updated the model in the most recent revision after going through some translations of our configs to the OpenConfig model and running into some issues.  The updated version looks more like the following:

list prefix {
          key "address masklength masklength-range";

          leaf address {
            type inet:ip-address;
          }

          leaf masklength {
            type uint8;
          }

          leaf masklength-range {
            type string {
              pattern '^([0-9]+\.\.[0-9]+)|exact$';
            }
         }
}

The model used address and a separate masklength so that range checking could be performed on the mask.   We've since removed the range-checking in favor of simplifying to keep a single prefix list for both address types, ipv4 and ipv6.

The original model had the problem you mention, which is that all keys must be mandatory, including masklength-range, which meant there was no simple way to express an exact prefix other than, e.g., 21..21 which we didn't think was desirable.  Changing the masklength-range to a string allows a more flexible pattern (including an 'exact' setting).  The masklength-range is included in the keys to make the list have unique members.

I think we could also consider your suggestion to use a inet:ip-prefix instead of address since we're not doing range-checking on the masklength in the current approach -- will discuss with the co-authors.

Agree with your suggestion to make the XML examples more conformant (they should certainly validate), though we've only been using ad-hoc namespaces for models that are not IETF WG models so far.  My understanding is that this is the recommended practice.

thanks.
-- Anees


On Wed, May 27, 2015 at 5:24 AM, Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

I have read the document and I have a small comment.

- You define a list 'prefix' in the list 'prefix-set' which is keyed
  by three leafs. As a result, all three leafs are mandatory. Your XML
  instance snipped in section 10 does not validate because it is
  missing mandatory key elements. I wonder (a) why did you not use
  inet:ip-prefix instead of the pair inet:ip-address and a unit8
  masklength. And given the desire to represent a prefix range, would
  a special syntax not make sense, e.g. an extension of ip-prefix,
  lets call it ip-prefix-range, that allows to express a range of
  prefixes:

  10.3.192.0/21-24<http://10.3.192.0/21-24> -> 10.3.192.0/21<http://10.3.192.0/21>
                      10.3.192.0/22<http://10.3.192.0/22>
                      10.3.192.0/23<http://10.3.192.0/23>
                      10.3.192.0/24<http://10.3.192.0/24>

  If the '-24' part is made optional, your prefix list will be
  collapsed to a simple

  list prefix {
      key prefix-range;

      leaf prefix-range {
          type ip-prefix-range;
      }
  }

  Such an ip-prefix-range type may even be a useful addition to
  ietf-inet-types.

- The XML snippets are nice but it would be cool if they were using
  proper namespaces and validate against the data model. Perhaps
  something to consider for -01. The pyang tutorial provides examples
  how to validate XML snippets against YANG definitions.

/js

--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]<tel:%2B49%20421%20200%203587>         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]<tel:%2B49%20421%20200%203103>         <http://www.jacobs-university.de/>

_______________________________________________
Rtg-yang-coord mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtg-yang-coord

_______________________________________________
Rtg-yang-coord mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/rtg-yang-coord