Re: I-D Action: draft-ietf-rtgwg-policy-model-13

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

Hi Tom, 

On 6/1/20, 6:53 AM, "rtgwg on behalf of t petch" <[e-mail] on behalf of [e-mail]> wrote:

    I have some doubts about this I-D. 

Hopefully, I can assuage your doubts. 

    -01 had four authors; -13 has four authors.  None are the same yet much
    of the text in the I-D is the same.

As excellent observation - the original authors had no ambition to complete the draft. There are listed in the acknowledgments. 

    NSSA could be added to the Terminology and/or expanded on first use.

Fixed. 

    Policy subroutines sound interesting - if there is one example I would
    find useful it would be one involving subroutines.

We could look at this. 

    10 YANG modules
    I only see one singular

Fixed. 

    XXXX is used as a placeholder for two different I-D

I've fixed this though I don't see the placeholders references as being ambiguous in the context. 

    I like the reference to RFC2178, RFC5130 but they need to appear in the
    I-D References and more YANG reference clauses would not come amiss

Fixed. 

           typedef metric-modification-type {
    .....
                       If the result would exceed the maximum metric
                    (0xffffffff), set the metric to the maximum.";
    OSPF has a 16 bit link metric, a 24 bit route metric as defined in
    ospg-yang.  Defining a maximum of 0xffffffff seems problematic. Add two
    to 16777215 and you get one.
    The other LSR protocol has a 6 or 24 or 32 bit metric depending on where
    you look.
 
The setting of the metric is independent of the application of the policy. As with other components of a routing policy, it is up to the network engineer defining the policy to define a policy that matches the context. 

                 "The prefix member in CIDR notation -- "
    member of what?  My prefix are a number!

I've removed CIDR as it is not used in RFC RFC 6021. 

             leaf mask-length-upper {
    the example implies that upper and lower must both be present which I do
    not see in the YANG.  Both upper and lower are part of the YANG key of
    the list which also suggests that both need to be present

You are correct - they are both required to be part of the key. If they are not part of the key, you would not be able to have multiple rules with the same prefix. We could change this to have prefix sequence number or name but this would diverge from the OpenConfig model unnecessarily. 

           grouping match-proto-route-type-condition {
    gets a bit long; here and elsewhere, is 'proto' needed as part of the
    identifiers?

I agree - will change condition but keep identity for protocol types to match as proto-route-type. 

               container prefix-sets {
                   leaf mode {
    I am not a fan of features - Cartesian explosion - but wonder if one is
    called for here at least for mixed mode

I am going to start a discussion on removing "mixed" since I know of no implementations.  

Thanks,
Acee

    Tom Petch
    >
    > ----- Original Message -----
    > From: <[e-mail]>
    > To: <[e-mail]>
    > Cc: <[e-mail]>
    >

    _______________________________________________
    rtgwg mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/rtgwg