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

[Anees Shaikh <[e-mail]>]

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]
> <[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
> <https://github.com/YangModels/yang/tree/master/experimental/openconfig>
>  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
>