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

[Anees Shaikh <[e-mail]>]

hi Acee, thanks for the comments -- we debated these same questions :-)

This approach was based on the wish to avoid operators having to worry
about specifying an ipv4 prefix list separately from an ipv6 -- no major
implementation has this separation today (though it could be considered).

If using inet:ip-prefix type instead of inet:ip-address + masklength buys
us some range checking in the pattern , maybe that's another reason to
switch to using that union type instead.  We will discuss making that
update.

You're right that with a string we don't do checking on the
masklength-range field.  As I mentioned earlier in the thread, this was to
accommodate a simple way to express an exact prefix (several
implementations do something similar).

Among OpenConfig operators, after some debate, we generally try to balance
the amount of validation in the model itself, with maintaining flexibility
and simplicity.  In other words, we don't believe the model needs to
prevent every conceivable error -- the implementation also has to
participate by rejecting invalid / unsupported configuration.  That said,
where it's easy to add validation, we have tried to include it, though
ranges, defaults, min/max values, etc. get harder when trying to build
something vendor-neutral.

Same applies to your correct comment that the current construct
theoretically allows one to mix address types in the prefix list.
Interestingly, some implementations allow you to create such a list, but
fail later when you try to use it in a policy.   We've chosen for now to
allow it (again for simplicity), but explicitly say in the description that
most implementations will reject a prefix-list with mixed address types.

thanks.
-- Anees



On Wed, May 27, 2015 at 9:57 AM, Acee Lindem (acee) <[e-mail]> wrote:

>
>  On May 27, 2015, at 12:47 PM, Acee Lindem (acee) <[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]>
> Date: Wednesday, May 27, 2015 at 12:09 PM
> To: Juergen Schoenwaelder <[e-mail]>de>, Routing
> YANG <[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]> 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 -> 10.3.192.0/21
>>                       10.3.192.0/22
>>                       10.3.192.0/23
>>                       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]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>
>
>    _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>
>