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

From: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 26 Dec 2014 00:35:53 +0000

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" <[email-masked]> 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 [[email-masked]] 代表 Susan Hares
>[[email-masked]]
>发送时间: 2014年12月20日 7:09
>收件人: 'Jeff Tantsura'; 'Acee Lindem (acee)';
>[email-masked]; 'Robert Raszuk'
>抄送: [email-masked]; '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:[email-masked]] On Behalf Of
>Jeff Tantsura
>Sent: Friday, December 19, 2014 4:36 PM
>To: Acee Lindem (acee); [email-masked]; Robert Raszuk
>Cc: [email-masked]; 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, "[email-masked]"
>><[email-masked]> wrote:
>>
>>>And question : Who is interested to start now the work on standard
>>>routing policy ?
>>>
>>>
>>>-----Original Message-----
>>>From: Rtg-yang-coord [mailto:[email-masked]] On
>>>Behalf Of [email-masked]
>>>Sent: Friday, December 19, 2014 12:59
>>>To: Robert Raszuk
>>>Cc: [email-masked]; 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: [email-masked] [mailto:[email-masked]] 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;
>>>[email-masked]; 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,  <[email-masked]>
>>>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: [email-masked] [mailto:[email-masked]] On Behalf Of
>>>> Robert Raszuk
>>>> Sent: Wednesday, December 17, 2014 23:28
>>>> To: Jeff Tantsura
>>>> Cc: Acee Lindem (acee); Dean Bogdanovic; [email-masked];
>>>> 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
>>>><[email-masked]> 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) <[email-masked]>
>>>>>>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 <[email-masked]>
>>>>>>>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 <[email-masked]>
>>>>>>>>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
>>>>>>>>><[email-masked]> 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
>>>>>>> [email-masked]
>>>>>>> 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
>>>[email-masked]
>>>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
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>_______________________________________________
>Rtg-yang-coord mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Anees Shaikh <[email-masked]>
Date: Fri, 26 Dec 2014 01:53:16 +0000

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.

---

From: Qin Wu <[email-masked]>
Date: Fri, 26 Dec 2014 02:16:08 +0000

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:[email-masked]] 代表 Anees Shaikh
发送时间: 2014年12月26日 9:53
收件人: Acee Lindem (acee); Lizhenbin; Susan Hares; Jeff Tantsura; [email-masked]; Robert Raszuk
抄送: [email-masked]; 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.

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).

On Thu Dec 25 2014 at 4:36:02 PM Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>> wrote:
Robin,

Thanks,
Acee

On 12/25/14, 8:33 AM, "Lizhenbin" <[email-masked]<mailto:[email-masked]>> wrote:

>发件人: Rtg-yang-coord [[email-masked]<mailto:[email-masked]>] 代表 Susan Hares
>[[email-masked]<mailto:[email-masked]>]
>发送时间: 2014年12月20日 7:09
>[email-masked]<mailto:[email-masked]>; 'Robert Raszuk'
>抄送: [email-masked]<mailto:[email-masked]>; 'Dean Bogdanovic'; 'Ladislav Lhotka'
>From: Rtg-yang-coord [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>Jeff Tantsura
>To: Acee Lindem (acee); [email-masked]<mailto:[email-masked]>; Robert Raszuk
>Cc: [email-masked]<mailto:[email-masked]>; Dean Bogdanovic; Ladislav Lhotka
>>On 12/19/14, 7:00 AM, "[email-masked]<mailto:[email-masked]>"
>><[email-masked]<mailto:[email-masked]>> wrote:
>>
>>>From: Rtg-yang-coord [mailto:[email-masked]<mailto:[email-masked]>] On
>>>Behalf Of [email-masked]<mailto:[email-masked]>
>>>Cc: [email-masked]<mailto:[email-masked]>; Acee Lindem (acee); Dean Bogdanovic; Jeff
>>>From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Robert
>>>Raszuk
>>>[email-masked]<mailto:[email-masked]>; Ladislav Lhotka
>>>On Fri, Dec 19, 2014 at 11:03 AM,  <[email-masked]<mailto:[email-masked]>>
>>>wrote:
>>>> Hi,
>>>>
>>>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>>>> Robert Raszuk
>>>> Cc: Acee Lindem (acee); Dean Bogdanovic; [email-masked]<mailto:[email-masked]>;
>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) <[email-masked]<mailto:[email-masked]>>
>>>>>>wrote:
>>>>>>
>>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic <[email-masked]<mailto:[email-masked]>>
>>>>>>>wrote:
>>>>>>>
>>>>>>> Robert,
>>>>>>>
>>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk <[email-masked]<mailto:[email-masked]>>
>>>>>>>>wrote:
>>>>>>>>
>>>>>>>> Dean, all
>>>>>>>>
>>>>>>>>><[email-masked]<mailto:[email-masked]>> wrote:
>>>>>>> [email-masked]<mailto:[email-masked]>
>>>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>
>[email-masked]<mailto:[email-masked]>

_______________________________________________
Rtg-yang-coord mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtg-yang-coord