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

[<[e-mail]>]

> It is better that the routing policy yang models should be decoupled with BGP models.

+1
It would be easier to define a "simple" policy framework and then let each protocol augment it with its own parameters.


-----Original Message-----
From: Lizhenbin [mailto:[e-mail]] 
Sent: Monday, January 05, 2015 19:15
To: Acee Lindem (acee); Susan Hares; 'Jeff Tantsura'; LITKOWSKI Stephane SCE/IBNF; 'Robert Raszuk'
Cc: [e-mail]; 'Dean Bogdanovic'; 'Ladislav Lhotka'
Subject: 答复: 答复: [Rtg-yang-coord] issue :R01: route filters

Hi Acee,
Firstly I would like to make the yang models we proposed to be an input to the process and we hope more models incorporated in the draft would help promote the process. Secondly I do not think the current BGP yang models are satisfactory though it incorporates the routing policy. For ISIS yang models there are 87 pages for the draft draft-ietf-isis-yang-isis-cfg-01. For BGP, there should be at least more than 100 pages. You can see there are more than 50 pages for the draft of the routing policy yang models, draft-yan-rtgwg-routing-policy-yang-00. If the BGP yang models incoporate the routing policy models and the draft can be refined better, there may be near 200 pages. But now there is only 40 pages for the draft draft-zhdankin-netmod-bgp-cfg-01. There are following things I would like to suggest:
1. Current BGP yang models are far from the actual usage; 2. It may be impossible to accept so huge draft with 200 pages; 3. The incoporated routing policy yang models may be just to slow down the standard process of BGP yang models since the policy is more flexible and harder to be unified than the protocol behavior. 
4. It is better that the routing policy yang models should be decoupled with BGP models.


Regards,
Robin





________________________________________
发件人: Acee Lindem (acee) [[e-mail]]
发送时间: 2014年12月26日 8:35
收件人: Lizhenbin; Susan Hares; 'Jeff Tantsura'; [e-mail]; 'Robert Raszuk'
抄送: [e-mail]; 'Dean Bogdanovic'; 'Ladislav Lhotka'
主题: Re: 答复: [Rtg-yang-coord] issue :R01: route filters

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

_________________________________________________________________________________________________________________________

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.