Hi Acee, please see my comments inline.
"Acee Lindem (acee)" <[email protected]> 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. 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. > 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. I can imagine filtering system-generated direct routes. > 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. 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. > > 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. 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. 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. 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 > P.S. netmod list bcc’ed. This discussion should take place on > [email protected]. 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 > > > > > > On 11/11/14, 4:58 PM, "Acee Lindem (acee)" <[email protected]> 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 protected] >>https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > Rtg-yang-coord mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtg-yang-coord -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
