Subject: Re: [netmod] High Level Comments on draft-ietf-netmod-rtg-cfg-16.txt

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 18 Nov 2014 21:24:33 +0000

First, let me explain why I requested that the route-filters be removed
from the model. What I don't like about the route-filters is that they
are merely place-holders placed at a point-of-attachment which I don't
necessarily agree with.  Although we may end up with something similar,
these definitions should be in a more complete routing
policy model. Additionally, I believe it is obvious that there will
be both generic policy and protocol specific policy (e.g., BGP). If
these route-filters are to be included, there should be more guidance
as to precisely how they are to be used. Given their point-of-attachment,
they should clearly only be used for generic routing policy. Note that
for the two routing protocol instances (static and connected) defined
in draft-ietf-netmod-rtg-cfg, the import filters aren't even applicable.
This fact alone would suggest that this may not be the right
point-of-attachment for such routing policy. However, if I'm in the
minority, they can be retained for TBD augmentation.

As for the interface list in the routing-instance, I think it is
obvious that one should not define the address space for interface
disjointly from the IPv4/IPv6 interface addresses. That is why I
would recommend augmenting the RFC 7273 objects with a reference
to the routing instance rather having a disjoint interface
list in routing-instance as proposed.

Thanks,
Acee
P.S. netmod list bcc’ed. This discussion should take place on
[email-masked].

On 11/11/14, 4:58 PM, "Acee Lindem (acee)" <[email-masked]> wrote:

>I have two rather substantive comments on the draft we will be discussing
>in tomorrow¹s rtgwg meeting.
>
>   1. The draft includes stub definitions for import/export routing
>filters with the guidance that these should be augmented. I would like to
>see these removed from this draft as the whole area of routing policy
>should be worked on by a multi-vendor team similar to what is being done
>for the routing protocols. I don¹t think the direction should be set for
>routing policy based on these stub definitions.
>
>   2. The draft defines a list of interfaces that correspond to a
>routing-instance. The routing-instance binds the physical interface (RFC
>RFC 7273) to an address space. However, the IPv4/IPv6 interface addresses
>are specified via the YANG model in RFC 7277. I really don¹t like this
>disjoint specification. Rather, "/if:interfaces/if:interface"  in RFC 7273
>should be augmented in a reference to the routing instance. Additionally,
>the neighbor discovery definitions should augment the ipv6 container in
>RFC 7277). 
>
>I also have one question for the RTG WG - do we want this model to specify
>the precise forwarding behavior?
>
>  The draft states that ³backup next-hops are only used if no primary
>next-hops exist." This will relegate all implementations to the same IPFRR
>behavior. I don¹t think that this should be specified in this draft.
>
>Thanks,
>Acee 
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Nov 2014 13:35:46 +0000

Re-adding [email-masked] due to popular request.

On 11/19/14, 7:40 AM, "Martin Bjorklund" <[email-masked]> wrote:

>Ladislav Lhotka <[email-masked]> wrote:
>> Hi Acee,
>> 
>> please see my comments inline.
>> 
>> "Acee Lindem (acee)" <[email-masked]> writes:
>> 
>> > First, let me explain why I requested that the route-filters be
>> > removed from the model. What I don't like about the route-filters is
>> > that they are merely place-holders placed at a point-of-attachment
>> > which I don't necessarily agree with.  Although we may end up with
>> > something similar, these definitions should be in a more complete
>> > routing policy model. Additionally, I believe it is obvious that there
>> > will
>> 
>> I don't think the ietf-routing module preempts any further work on a
>> policy model. And if the points-of-attachment turn out to be wrong, we
>> can write a new module - nothing is cast in stone and I expect the
>> module will have to be redone anyway after some experience will have
>> been collected.
>
>But then it doesn't hurt to wait with these "attachment points" until
>at least the first policy model is being written, right?  They can
>then either be defined in an update to this model, or in a separate
>model that augments this one.

My point is that this may set us off in the wrong direction and be a
source of future confusion and debate. If others believe the existing stub
policies are a good start, they should speak up.

>[...]
>> It is IMO subjective whether the assignment of interfaces to routing
>> instances should be done in interface configuration or in routing
>> instance configuration. As it is now, the following procedure could work
>> fine:
>> 
>> 1. Define routing instances (this has to be done in any case).
>> 2. Assign interfaces to routing instances in routing instance
>>    configuration via references to interfaces in the main interface
>>    list.
>> 3. Assign addresses to interfaces in main interface configuration.
>> 
>> The system then has all information to be able to resolve potential
>> conflicts in IP addresses belonging to different routing instances.
>
>To be very clear, is this what you propose:
>
>  augement /if:interfaces/if:interface {
>    leaf routing-instance {
>      type routing-instance-ref;
>    }
>  }
>
>... and remove /routing/routing-instance/interfaces?

Either here or augment ietf-ip (RFC 7277) in a similar manner. I also
think the definition of the ipv6-router-advertisements should augment the
ipv6 container in ietf-ip rather than on this misplaced list of
interfaces. 

Thanks,
Acee 

>
>I think this would be equivalent to your current model, in the sense
>of *what* you can express.
>
>> Maybe there are some implementation-related issues that I am missing,
>> so I am not against the change you propose but I'd like to know sound
>> reasons before applying it.
>
>I think Acee provided a good reason:
>
>> > one should not define the address space for interface
>> > disjointly from the IPv4/IPv6 interface addresses
>
>
>
>
>/martin

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 19 Nov 2014 13:44:52 +0000

Hi Lada, 

I think we are at the point of agreeing to disagree. See inline.

>module will have to be redone anyway after some experience will have

Sounds like a good reason to remove the route-filters to me.

>
>On the other hand, several modules for routing protocols are being
>developed, as you know. For any practical use, some way of specifying
>routing policy will be needed, and the current framework can serve this
>purpose for now. Folks working on the BGP module already included some
>BGP-specific policy configuration, and I will try to work with them on
>integrating it with route filters in ietf-routing. Vendors can also
>define their proprietary filtering frameworks in the mean time. I am
>myself working on one for the BIRD routing daemon.

You speak like your model is cast in stone. I, for one, believe that both
protocol specific and generic policy should be attached in the routing
protocol instance itself. I think this is much more intuitive and matches
the prevailing industry model. Compatibility with Bird should not dictate
the industry model.

>I can imagine filtering system-generated direct routes.
>
>The idea was that any future routing protocol module that's designed
>according to the guidelines in the I-D could participate in routing
>policies without further ado.
>
>>

The question is not whether it could be made to work but whether it is the
most optimal hierarchy.

Thanks,
Acee 

>FYI, we found a solution for the VPN issue that Jeff Haas raised at the
>mike, and Jeff promised to write a review of the routing-cfg draft.
>
>>
>> Thanks,
>> Acee
>Agreed, I don't think NETMOD WG has to be involved at this stage. If
>we stumble upon any YANG-specific issues, I will take them to the NETMOD
>mailing list separately.
>
>Thanks, Lada
>
>>
>>
>>
>>
>>
>> Rtg-yang-coord mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>-- 
>Ladislav Lhotka, CZ.NIC Labs
>PGP Key ID: E74E8C0C

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 14:45:59 +0100

> policies are a good start, they should speak up.

+1

> ipv6 container in ietf-ip rather than on this misplaced list of

An advantage of this misplaced list of interfaces is that it is supposed to contain only network layer interfaces whereas if:interface is a flat list that contains interfaces of all layers including those where RAs don’t make sense at all.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 14:57:35 +0100

> the prevailing industry model. Compatibility with Bird should not dictate

Certainly not, but in JUNOS “control points” for routing policies are also between routing protocols and routing tables. I understand Cisco way is different but I think direct redistribution between protocols can always be emulated via a routing table whereas the opposite is not true.

> The question is not whether it could be made to work but whether it is the

What’s an optimal hierarchy is highly subjective, so I’d really like others to speak up.

Lada