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

[Qin Wu <[e-mail]>]

Good question, I think I2RS has already devled into this aspect, e.g.,
a. Policy framework draft
https://tools.ietf.org/html/draft-atlas-i2rs-policy-framework-00
b. Policy based routing drafts 
https://tools.ietf.org/html/draft-hareskini-i2rs-pbr-info-model-00
https://tools.ietf.org/id/draft-kini-i2rs-pbr-info-model-00.txt
I think these drafts are quite related to what you are looking for.
Would it be great to restart some discussion on these drafts first and see what is missing in these drafts
And if these drafts can address the requirements we want to set for this topic?

Regards!
-Qin
-----邮件原件-----
发件人: Rtg-yang-coord [mailto:[e-mail]] 代表 [e-mail]
发送时间: 2014年12月19日 20:01
收件人: LITKOWSKI Stephane SCE/IBNF; Robert Raszuk
抄送: [e-mail]; Acee Lindem (acee); Dean Bogdanovic; Jeff Tantsura; Ladislav Lhotka
主题: Re: [Rtg-yang-coord] issue :R01: route filters

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]; 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