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 protected]. 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 _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
