On 19 Nov 2014, at 14:44, Acee Lindem (acee) <[email protected]> wrote:
> Hi Lada, > > I think we are at the point of agreeing to disagree. See inline. > > On 11/19/14, 7:12 AM, "Ladislav Lhotka" <[email protected]> wrote: > >> 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. > > 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. 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. > > >> >>> 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 question is not whether it could be made to work but whether it is the > most optimal hierarchy. What’s an optimal hierarchy is highly subjective, so I’d really like others to speak up. Lada > > Thanks, > Acee > > > >> >> 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 > > _______________________________________________ > 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
