Re: [Rtg-yang-coord] issue :R01: route filters

[Qin Wu <[e-mail]>]

Yes, you are right. This feature is not supported in the RFC6020.
What about using leafref, here is an example:
module foo {
namespace "urn:ietf:params:xml:ns:yang:foo";
  prefix "foobar";
 container c1 {
    list l1 {
      key name;
      leaf name {
        type string;
      }
        container conditions {
          leaf-list call-foo {
            type leafref {
              path "/foobar:c1/foobar:l1/" +
                  "foobar:name";
            }
          }
        }

      }
    }
  }
Is this some kind of recursive model?

Regards!
-QIn
-----邮件原件-----
发件人: Ladislav Lhotka [mailto:[e-mail]] 
发送时间: 2015年1月13日 18:30
收件人: Qin Wu
抄送: Anees Shaikh; [e-mail]; [e-mail]
主题: Re: [Rtg-yang-coord] issue :R01: route filters


> On 13 Jan 2015, at 11:24, Qin Wu <[e-mail]> wrote:
> 
> Anees:
> I am wondering how does nested policy work, recursive by using grouping and allow grouping to contain itself?  why there is no attribute to limit the depth of the recursion or nest depth?

YANG groupings cannot be used recursively, see sec. 7.11 in RFC 6020.

Lada

>  
> Regards!
> -Qin
> 发件人: Rtg-yang-coord [mailto:[e-mail]] 代表 
> [e-mail]
> 发送时间: 2015年1月6日 18:26
> 收件人: Anees Shaikh; Qin Wu
> 抄送: [e-mail]
> 主题: Re: [Rtg-yang-coord] issue :R01: route filters
>  
> Hi,
>  
> Great to hear. In the draft, IMO, it will be important to focus on explanations of how your policy framework is working. For now, Yang definition is quite a detail, we must first have a consensus on how it will work.
>  
> Stephane
>  
>  
> From: Anees Shaikh [mailto:[e-mail]]
> Sent: Monday, January 05, 2015 17:40
> To: LITKOWSKI Stephane SCE/IBNF; Qin Wu
> Cc: [e-mail]
> Subject: Re: [Rtg-yang-coord] issue :R01: route filters
>  
> hi Stephane, yes, we will put together a draft for the routing model -- hopefully by next week.  We are discussing a couple of extensions that we hope to resolve by then.  The YANG code with the current model is in the YangModels github repo (experimental/openconfig/policy) per my earlier mail.
>  
> thanks.
> -- Anees
>  
> On Mon Jan 05 2015 at 3:37:34 AM <[e-mail]> wrote:
>  
> Thanks for pointing this openconfig initiative, I already taked about it with Rob Shakir offline and there are good things in it.
>  
> Do openconfig authors will publish an IETF draft soon for this routing policy model, so we can work on it as a base doc ? or do we need to restart something ?
>  
>  
> From: Qin Wu [mailto:[e-mail]]
> Sent: Friday, December 26, 2014 03:16
> To: Anees Shaikh; Acee Lindem (acee); Lizhenbin; Susan Hares; Jeff 
> Tantsura; LITKOWSKI Stephane SCE/IBNF; Robert Raszuk
> Cc: [e-mail]; Dean Bogdanovic; Ladislav Lhotka; David 
> Sinicrope
> Subject: RE: [Rtg-yang-coord] RE: issue :R01: route filters
>  
> Anees:
> Thanks for sharing the link:
> https://github.com/YangModels/yang/tree/master/experimental/openconfig
> /policy
> I think that helps the discussion.
>  
> Regards!
> -Qin
> 发件人: Rtg-yang-coord [mailto:[e-mail]] 代表 Anees 
> Shaikh
> 发送时间: 2014年12月26日 9:53
> 收件人: Acee Lindem (acee); Lizhenbin; Susan Hares; Jeff Tantsura; 
> [e-mail]; Robert Raszuk
> 抄送: [e-mail]; Dean Bogdanovic; Ladislav Lhotka
> 主题: Re: [Rtg-yang-coord] 答复: issue :R01: route filters
>  
> 
> The OpenConfig network operators working group recently published an update to our BGP data model that may be of interest to this discussion.  It also included a generalization of routing policy into a separate model to be used across multiple routing protocols, VRFs, etc.   Our view is that it is possible to come up with routing policy expression that can be mapped relatively easily to a number of widely used implementations.   I'm pasting the announcement email below with a link to the modules for anyone interested.
>  
> thanks.
> -- Anees
>  
> -------------
> hi Folks,  the working group has published a new version of the BGP model with a number of changes based on additional operator input as well as from the broader community.
>  
> The updated models are available in the YangModels public github repo.
>  
> Highlights of the changes:
>  
> Refactored multiprotocol module with explicit set of supported 
> AFI-SAFI combinations (using YANG identities) in a flattened list.
> Focus was on common config with more AFI-SAFI specific configuration 
> forthcoming.
>  
> Refactored BGP policy module to work with a new general routing policy module (see below) by augmenting it with BGP-specific policy options (conditions and actions).
>  
> Several new configuration items added to base bgp module.
>  
> The bgp-operational module is largely unchanged -- the next release is 
> expected to contain a significant update.
>  
> Initial version of a general routing-policy module and associated 
> reusable types module for policy.  The routing policy module is 
> currently augmented by the bgp-policy module for bgp-specific routing 
> policy options.
>  
> The IGP policy items in this version of the module are limited to 
> generic items available in widely used protocols like IS-IS and OSPF.
>  
> On Thu Dec 25 2014 at 4:36:02 PM Acee Lindem (acee) <[e-mail]> wrote:
> Robin,
> 
> As you have noted, there has already been some prior work on routing 
> policy. In fact, all the BGP drafts have elements of routing policy.
> Therefore, the fact that you have chartered work on routing policy is 
> by no means a guarantee that your work will become the standard. It 
> can, however, be an input to the process.
> 
> Thanks,
> Acee
> 
> On 12/25/14, 8:33 AM, "Lizhenbin" <[e-mail]> wrote:
> 
> >Hi folks,
> >Regarding the Yang models, I have following opinion for discussion:
> >1. We think the forwarding, topology and policy are the basic 
> >components for I2RS. It is better the Yang models for the policy 
> >should be defined in the I2RS WG instead of RTGWG.
> >2. Though the route policy has much relation with BGP, we think the 
> >policy should be independent since it may be used for other protocols.
> >Now IP prefix list is defined in BGP yang models. We hope it should 
> >be defined in the routing policy. The decoupling of the policy from 
> >the protocol may benefit the Yang model definition for the potocol.
> >3. Though we are defining the Yang models for the route policy, we 
> >are aware they are not flexible enough for some scenarios. Could we 
> >start to standardize some policy specific language such as RPSL while 
> >define the Yang models for the routing policy?
> >
> >
> >Regards,
> >Robin
> >
> >
> >
> >
> >
> >________________________________________
> >发件人: Rtg-yang-coord [[e-mail]] 代表 Susan Hares 
> >[[e-mail]]
> >发送时间: 2014年12月20日 7:09
> >收件人: 'Jeff Tantsura'; 'Acee Lindem (acee)'; 
> >[e-mail]; 'Robert Raszuk'
> >抄送: [e-mail]; 'Dean Bogdanovic'; 'Ladislav Lhotka'
> >主题: Re: [Rtg-yang-coord] issue :R01: route filters
> >
> >Stephen:
> >
> >I am interested.  We having routing policy discussion in I2RS 
> >relating PBR and policy.  It needs to link to a base specification.
> >
> >Sue
> >
> >-----Original Message-----
> >From: Rtg-yang-coord [mailto:[e-mail]] On 
> >Behalf Of Jeff Tantsura
> >Sent: Friday, December 19, 2014 4:36 PM
> >To: Acee Lindem (acee); [e-mail]; Robert Raszuk
> >Cc: [e-mail]; Dean Bogdanovic; Ladislav Lhotka
> >Subject: Re: [Rtg-yang-coord] issue :R01: route filters
> >
> >I’d like to be involved, as well as giving it a home in rtgwg
> >
> >Cheers,
> >Jeff
> >
> >
> >
> >
> >-----Original Message-----
> >
> >>
> >>On 12/19/14, 7:00 AM, "[e-mail]"
> >><[e-mail]> wrote:
> >>
> >>>And question : Who is interested to start now the work on standard 
> >>>routing policy ?
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: Rtg-yang-coord [mailto:[e-mail]] On 
> >>>Behalf Of [e-mail]
> >>>Sent: Friday, December 19, 2014 12:59
> >>>To: Robert Raszuk
> >>>Cc: [e-mail]; Acee Lindem (acee); Dean Bogdanovic; 
> >>>Jeff Tantsura; Ladislav Lhotka
> >>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters
> >>>
> >>>Robert,
> >>>
> >>>You are touching an interesting point :) In fact there are two ways 
> >>>of viewing thinks :
> >>>- service providers/customers who would like to use only standard 
> >>>models to facilitate network provision & operation
> >>>- vendors who may not want to make development to implement new 
> >>>features to be compliant with a standard yang model  (as dev cost 
> >>>money). As you mentioned, operation of boxes is today a key 
> >>>differentiator when choosing a vendor.
> >>>We clearly this divergence today in produced Yang model (operator 
> >>>authors models vs vendor authors model)
> >>>
> >>>As a service provider, I'm clearly pushing to use only standard 
> >>>model at least for most of the base structure of services and I 
> >>>will push my vendors to support it as more as possible. I would say 
> >>>that more than 90% of parameters of a service are common to all 
> >>>implementations (just details are changing  : localization of the 
> >>>config statement or granularity of the parameter). So I think that 
> >>>creating usable standard model can work. The remaining x% can be 
> >>>addressed by vendor
> >extensions.
> >>>
> >>>Coming back to routing policies. I do think that restarting a new 
> >>>framework from stratch is the right way to do it. And as any 
> >>>protocol extension or feature standardized in IETF, it will be up 
> >>>to customers to request their vendors for implementations.
> >>>
> >>>Today routing policy management between different vendors is crazy.
> >>>Consider you have a Vendor X network with widely deployed complex 
> >>>routing policies, and you want to introduce to vendor Y, 
> >>>translation of routing policies from language X to Y is a very complex work.
> >>>
> >>>Moreover we can see that framework of policy model is already 
> >>>existing for internet registries using RPSL.
> >>>
> >>>I do not know today where this Yang initiative will go ... but I 
> >>>will prone a consensus on strong adoption of standard YANG models 
> >>>rather than vendor specific only.
> >>>
> >>>
> >>>Stephane
> >>>
> >>>
> >>>
> >>>
> >>>-----Original Message-----
> >>>From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> >>>Robert Raszuk
> >>>Sent: Friday, December 19, 2014 11:10
> >>>To: LITKOWSKI Stephane SCE/IBNF
> >>>Cc: Jeff Tantsura; Acee Lindem (acee); Dean Bogdanovic; 
> >>>[e-mail]@ietf.org; Ladislav Lhotka
> >>>Subject: Re: [Rtg-yang-coord] issue :R01: route filters
> >>>
> >>>Hi Stephane,
> >>>
> >>>That is going to be very interesting indeed. Considering that 
> >>>number of customers have paid vendors millions for customized 
> >>>extensions and only some of them made it to IETF drafts/rfcs.
> >>>
> >>>So what will most likely happen is general YANG model of not much 
> >>>use and zoo of proprietary vendor YANG extensions not compatible 
> >>>between implementations.
> >>>
> >>>Is this really where we want to go with this entire effort ?
> >>>
> >>>Best,
> >>>r.
> >>>
> >>>
> >>>On Fri, Dec 19, 2014 at 11:03 AM,  <[e-mail]>
> >>>wrote:
> >>>> Hi,
> >>>>
> >>>> I think working of BGP YANG is a good opportunity to start 
> >>>>working on policy framework.
> >>>> Work on protocols YANG is already hard due to vendor config 
> >>>>disprecancies, I expect policy work to be much harder ...
> >>>>
> >>>> But I think, there is an opportunity to start something new for 
> >>>>everyone (that may coexist with existing CLI policies) and not 
> >>>>looking at CLI translation (it will be impossible with policies).
> >>>>Then it would be up to service providers to request the support of 
> >>>>this by their favorite vendors.
> >>>>
> >>>> Best Regards,
> >>>>
> >>>> Stephane
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: [e-mail] [mailto:[e-mail]] On Behalf Of 
> >>>> Robert Raszuk
> >>>> Sent: Wednesday, December 17, 2014 23:28
> >>>> To: Jeff Tantsura
> >>>> Cc: Acee Lindem (acee); Dean Bogdanovic; [e-mail]; 
> >>>> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka
> >>>> Subject: Re: [Rtg-yang-coord] issue :R01: route filters
> >>>>
> >>>> So are you saying that formal YANG specification say for BGP by 
> >>>>design will not be compatible with some implementations ?
> >>>>
> >>>> Or are you saying that formal design say of BGP protocol will 
> >>>>have to wait few years till YANG for policy spec is complete ?
> >>>>
> >>>> Cheers,
> >>>> r.
> >>>>
> >>>> On Wed, Dec 17, 2014 at 11:14 PM, Jeff Tantsura 
> >>>><[e-mail]> wrote:
> >>>>> Yes, exactly, Robert - the behavior you have described is an 
> >>>>>implementation, not a formal specification.
> >>>>>
> >>>>> Regards,
> >>>>> Jeff
> >>>>>
> >>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) 
> >>>>>><[e-mail]>
> >>>>>>wrote:
> >>>>>>
> >>>>>> Why is this a problem if the default is to not to redistribute 
> >>>>>>routes between RIBs? Note that it isn¹t like we have a set of 
> >>>>>>approved routing protocol models that are dependent on this behavior.
> >>>>>> Acee
> >>>>>>
> >>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic 
> >>>>>>><[e-mail]>
> >>>>>>>wrote:
> >>>>>>>
> >>>>>>> Robert,
> >>>>>>>
> >>>>>>> Your proposal is very sensible and I think this is the best 
> >>>>>>> option
> >>>>>>>
> >>>>>>> Dean
> >>>>>>>
> >>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk 
> >>>>>>>><[e-mail]>
> >>>>>>>>wrote:
> >>>>>>>>
> >>>>>>>> Dean, all
> >>>>>>>>
> >>>>>>>> The way I read it currently in section 5.5 there are only two 
> >>>>>>>>route filters proposed (deny-all or allow-all). As we know 
> >>>>>>>>some routing protocols require explicit permission to operate (example:
> >>>>>>>>EBGP).
> >>>>>>>> If we remove even those two primitive filters there can be 
> >>>>>>>>impact  to other components.
> >>>>>>>>
> >>>>>>>> But I do support a separate work for YANG model for policy. I 
> >>>>>>>> do expect this to be a very interesting and involved work 
> >>>>>>>> considering significant diversity of policy languages across 
> >>>>>>>> all implementations today.
> >>>>>>>>
> >>>>>>>> Once that work is done we could retire section 5.5 of
> >>>>>>>> *-netmod-routing-*
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> r.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On Wed, Dec 17, 2014 at 10:09 PM, Dean Bogdanovic 
> >>>>>>>>><[e-mail]> wrote:
> >>>>>>>>> I'm in support of removing route filters from the routing 
> >>>>>>>>>cfg model. Route filters should be IMO part of the policy 
> >>>>>>>>>model, in which also ACL model belongs too. Actually, I would 
> >>>>>>>>>argue that the current ACL model is very suitable for route filters.
> >>>>>>>>>
> >>>>>>>>> Dean
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> Rtg-yang-coord mailing list
> >>>>>>> [e-mail]
> >>>>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >>>>>>
> >>>>
> >>>> _________________________________________________________________
> >>>> ___ __ ___________________________________________________
> >>>>
> >>>> Ce message et ses pieces jointes peuvent contenir des 
> >>>>informations confidentielles ou privilegiees et ne doivent donc 
> >>>>pas etre diffuses, exploites ou copies sans autorisation. Si vous 
> >>>>avez recu ce message par erreur, veuillez le signaler a 
> >>>>l'expediteur et le detruire ainsi que les pieces jointes. Les 
> >>>>messages electroniques etant susceptibles d'alteration, Orange 
> >>>>decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>>
> >>>> This message and its attachments may contain confidential or 
> >>>>privileged information that may be protected by law; they should 
> >>>>not be distributed, used or copied without authorisation.
> >>>> If you have received this email in error, please notify the 
> >>>>sender and delete this message and its attachments.
> >>>> As emails may be altered, Orange is not liable for messages that 
> >>>>have been modified, changed or falsified.
> >>>> Thank you.
> >>>>
> >>>
> >>>___________________________________________________________________
> >>>___
> >>>___
> >>>_
> >>>_______________________________________________
> >>>
> >>>Ce message et ses pieces jointes peuvent contenir des informations 
> >>>confidentielles ou privilegiees et ne doivent donc pas etre 
> >>>diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> >>>ce message par erreur, veuillez le signaler a l'expediteur et le 
> >>>detruire ainsi que les pieces jointes. Les messages electroniques 
> >>>etant susceptibles d'alteration, Orange decline toute 
> >>>responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>>This message and its attachments may contain confidential or 
> >>>privileged information that may be protected by law; they should 
> >>>not be distributed, used or copied without authorisation.
> >>>If you have received this email in error, please notify the sender 
> >>>and delete this message and its attachments.
> >>>As emails may be altered, Orange is not liable for messages that 
> >>>have been modified, changed or falsified.
> >>>Thank you.
> >>>
> >>>_______________________________________________
> >>>Rtg-yang-coord mailing list
> >>>[e-mail]
> >>>https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >>>
> >>>___________________________________________________________________
> >>>___
> >>>___
> >>>_
> >>>_______________________________________________
> >>>
> >>>Ce message et ses pieces jointes peuvent contenir des informations 
> >>>confidentielles ou privilegiees et ne doivent donc pas etre 
> >>>diffuses, exploites ou copies sans autorisation. Si vous avez recu 
> >>>ce message par erreur, veuillez le signaler a l'expediteur et le 
> >>>detruire ainsi que les pieces jointes. Les messages electroniques 
> >>>etant susceptibles d'alteration, Orange decline toute 
> >>>responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>>This message and its attachments may contain confidential or 
> >>>privileged information that may be protected by law; they should 
> >>>not be distributed, used or copied without authorisation.
> >>>If you have received this email in error, please notify the sender 
> >>>and delete this message and its attachments.
> >>>As emails may be altered, Orange is not liable for messages that 
> >>>have been modified, changed or falsified.
> >>>Thank you.
> >>>
> >>
> >
> >_______________________________________________
> >Rtg-yang-coord mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> >
> >_______________________________________________
> >Rtg-yang-coord mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> 
> _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> ______________________________________________________________________
> ___________________________________________________
>  
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> ______________________________________________________________________
> ___________________________________________________
>  
> Ce message et ses pieces jointes peuvent contenir des informations 
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, 
> exploites ou copies sans autorisation. Si vous avez recu ce message 
> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>  
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C