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

From: <[email-masked]>
Date: Mon, 5 Jan 2015 11:37:21 +0000

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

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) <[email-masked]<mailto:[email-masked]>> 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" <[email-masked]<mailto:[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]<mailto:[email-masked]>] 代表 Susan Hares
>[[email-masked]<mailto:[email-masked]>]
>发送时间: 2014年12月20日 7:09
>收件人: 'Jeff Tantsura'; 'Acee Lindem (acee)';
>[email-masked]<mailto:[email-masked]>; 'Robert Raszuk'
>抄送: [email-masked]<mailto:[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]<mailto:[email-masked]>] On Behalf Of
>Jeff Tantsura
>Sent: Friday, December 19, 2014 4:36 PM
>To: Acee Lindem (acee); [email-masked]<mailto:[email-masked]>; Robert Raszuk
>Cc: [email-masked]<mailto:[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]<mailto:[email-masked]>"
>><[email-masked]<mailto:[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]<mailto:[email-masked]>] On
>>>Behalf Of [email-masked]<mailto:[email-masked]>
>>>Sent: Friday, December 19, 2014 12:59
>>>To: Robert Raszuk
>>>Cc: [email-masked]<mailto:[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]> [mailto:[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]<mailto:[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]<mailto:[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]> [mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>
>_______________________________________________
>Rtg-yang-coord mailing list
>[email-masked]<mailto:[email-masked]>
>https://www.ietf.org/mailman/listinfo/rtg-yang-coord

_______________________________________________
Rtg-yang-coord mailing list
[email-masked]<mailto:[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.

---

From: "Russ White" <[email-masked]>
Date: Mon, 5 Jan 2015 07:18:56 -0500

> 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 ?

I would say we need to start something... I've entered a few comments into git on this model, but not certain how we work from there.

:-)

Russ

---

From: Anees Shaikh <[email-masked]>
Date: Mon, 05 Jan 2015 16:39:42 +0000

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 <[email-masked]> 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:[email-masked]]
> *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:* [email-masked]; Dean Bogdanovic; Ladislav Lhotka; David
> Sinicrope
> *Subject:* RE: [Rtg-yang-coord] RE: issue :R01: route filters
>
>
>
> Anees:
>
> *发件人**:* Rtg-yang-coord [mailto:[email-masked]
> <[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]>
> wrote:
>
> Robin,
>
> On 12/25/14, 8:33 AM, "Lizhenbin" <[email-masked]> wrote:
>
> >Hi folks,
> >发件人: Rtg-yang-coord [[email-masked]] 代表 Susan Hares
> >[[email-masked]]
> >发送时间: 2014年12月20日 7:09
> >[email-masked]; 'Robert Raszuk'
> >抄送: [email-masked]; 'Dean Bogdanovic'; 'Ladislav Lhotka'
> >From: Rtg-yang-coord [mailto:[email-masked]] On Behalf
> Of
> >Jeff Tantsura
> >To: Acee Lindem (acee); [email-masked]; Robert Raszuk
> >Cc: [email-masked]; Dean Bogdanovic; Ladislav Lhotka
> >>On 12/19/14, 7:00 AM, "[email-masked]"
> >><[email-masked]> wrote:
> >>
> >>>From: Rtg-yang-coord [mailto:[email-masked]] On
> >>>Behalf Of [email-masked]
> >>>Cc: [email-masked]; Acee Lindem (acee); Dean Bogdanovic; Jeff
> >>>From: [email-masked] [mailto:[email-masked]] On Behalf Of Robert
> >>>Raszuk
> >>>[email-masked]; Ladislav Lhotka
> >>>On Fri, Dec 19, 2014 at 11:03 AM,  <[email-masked]>
> >>>wrote:
> >>>> Hi,
> >>>>
> >>>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> >>>> Robert Raszuk
> >>>> Cc: Acee Lindem (acee); Dean Bogdanovic; [email-masked];
> >>>><[email-masked]> wrote:
> >>>>>> On Dec 17, 2014, at 2:12 PM, Acee Lindem (acee) <[email-masked]>
> >>>>>>wrote:
> >>>>>>
> >>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic <[email-masked]>
> >>>>>>>wrote:
> >>>>>>>
> >>>>>>> Robert,
> >>>>>>>
> >>>>>>>> On Dec 17, 2014, at 4:49 PM, Robert Raszuk <[email-masked]>
> >>>>>>>>wrote:
> >>>>>>>>
> >>>>>>>> Dean, all
> >>>>>>>>
> >>>>>>>>><[email-masked]> wrote:
> >>>>>>> [email-masked]
> >>>[email-masked]
> >[email-masked]
> >[email-masked]
> [email-masked]
> [email-masked]

---

From: Lizhenbin <[email-masked]>
Date: Mon, 5 Jan 2015 17:31:57 +0000

Hi Folks,

In fact, the route policy and BGP yang models proposed the tough issues for us all. For the past year many people always worried that the Yang models work may become the MIB work again: It is necessary, but the slow standard process cause the faster to adopt the private way and the missed features of the models make them to confine to the limited usage. For MIB, the new features were developed faster than the MIB standard. But now the situation is different. The features of different protocols are mature to satisfy different scenarios. Though there are difference beween different vendors' implementation, there is much common part. For BGP and route policy, some features have been used for more than ten years. I think we definitely could have a higher start for the Yang model work to incorporate as many featues as possible to propose more discussion at the beginning. That is why we release the draft-yan-rtgwg-routing-policy-yang-00 try to promote the route policy Yang model. And that is why I think the standard process of BGP Yang models is not satisfactory comparing with the ISIS and other yang models. This is not only because of the BGP. The BGP yang model work may have more effect owing to slowing down the standard process of Route policy, L3VPN, L2VPN and EVPN. We may lose some chance for the actual deployment will take effect faster and more complete than the final standard models.

Regards,

Robin

________________________________
发件人: Rtg-yang-coord [[email-masked]] 代表 Anees Shaikh [[email-masked]]
发送时间: 2015年1月6日 0:39
收件人: [email-masked]; Qin Wu
抄送: [email-masked]
主题: 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 <[email-masked]<mailto:[email-masked]>> wrote:

From: Qin Wu [mailto:[email-masked]<mailto:[email-masked]>]
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: [email-masked]<mailto:[email-masked]>; Dean Bogdanovic; Ladislav Lhotka; David Sinicrope
Subject: RE: [Rtg-yang-coord] RE: issue :R01: route filters

Anees:

Regards!
-Qin

thanks.
-- Anees

-------------

Thanks,
Acee

---

From: Lizhenbin <[email-masked]>
Date: Mon, 5 Jan 2015 18:14:46 +0000

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) [[email-masked]]
发送时间: 2014年12月26日 8:35
收件人: Lizhenbin; Susan Hares; 'Jeff Tantsura'; [email-masked]; 'Robert Raszuk'
抄送: [email-masked]; 'Dean Bogdanovic'; 'Ladislav Lhotka'
主题: Re: 答复: [Rtg-yang-coord] issue :R01: route filters

Robin,

Thanks,
Acee

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

>From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
>Jeff Tantsura

---

From: <[email-masked]>
Date: Tue, 6 Jan 2015 10:23:34 +0000

> 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:[email-masked]] 
Sent: Monday, January 05, 2015 19:15
To: Acee Lindem (acee); Susan Hares; 'Jeff Tantsura'; LITKOWSKI Stephane SCE/IBNF; 'Robert Raszuk'
Cc: [email-masked]; '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

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:

>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.
>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
>
>
>
>
>
>I am interested.  We having routing policy discussion in I2RS relating 
>PBR and policy.  It needs to link to a base specification.
>
>Sue
>
>Of Jeff Tantsura
>>>Cc: [email-masked]; Acee Lindem (acee); Dean Bogdanovic; 
>>>Jeff Tantsura; Ladislav Lhotka
>>>You are touching an interesting point :) In fact there are two ways 
>>>of viewing thinks :
>>>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 
>>>Moreover we can see that framework of policy model is already 
>>>existing for internet registries using RPSL.
>>>
>>>>>>>> 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.
>>>>>>>>
>>>> ___________________________________________________________________
>>>> _ __ ___________________________________________________
>>>>
>>>>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.
>>>>

---

From: <[email-masked]>
Date: Tue, 6 Jan 2015 10:25:52 +0000

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:[email-masked]]
Sent: Monday, January 05, 2015 17:40
To: LITKOWSKI Stephane SCE/IBNF; Qin Wu
Cc: [email-masked]
Subject: Re: [Rtg-yang-coord] issue :R01: route filters

thanks.
-- Anees

Anees:

Regards!
-Qin

thanks.
-- Anees

-------------

Thanks,
Acee

Thank you.

---

From: <[email-masked]>
Date: Mon, 5 Jan 2015 11:34:02 +0000

Anees:

Regards!
-Qin

thanks.
-- Anees

-------------

Thanks,
Acee

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 6 Jan 2015 21:15:28 +0000

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

I also agree with this proposal, as we can use such "simple" policy framework for COS model too

Dean

---

From: Qin Wu <[email-masked]>
Date: Tue, 13 Jan 2015 10:24:17 +0000

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?

Regards!
-Qin
发件人: Rtg-yang-coord [mailto:[email-masked]] 代表 [email-masked]
发送时间: 2015年1月6日 18:26
收件人: Anees Shaikh; Qin Wu
抄送: [email-masked]
主题: Re: [Rtg-yang-coord] issue :R01: route filters

Hi,

Stephane

Cc: [email-masked]<mailto:[email-masked]>

thanks.
-- Anees

Anees:

Regards!
-Qin

thanks.
-- Anees

-------------

Thanks,
Acee

Thank you.

Thank you.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Jan 2015 11:30:09 +0100

> On 13 Jan 2015, at 11:24, Qin Wu <[email-masked]> wrote:
> 
> Anees:

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

Lada

> 收件人: Acee Lindem (acee); Lizhenbin; Susan Hares; Jeff Tantsura; [email-masked]; Robert Raszuk
> 抄送: [email-masked]; Dean Bogdanovic; Ladislav Lhotka
> The updated models are available in the YangModels public github repo.
>  
> On Thu Dec 25 2014 at 4:36:02 PM Acee Lindem (acee) <[email-masked]> wrote:
> Robin,
> 

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

---

From: Qin Wu <[email-masked]>
Date: Tue, 13 Jan 2015 10:48:53 +0000

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:[email-masked]] 
发送时间: 2015年1月13日 18:30
收件人: Qin Wu
抄送: Anees Shaikh; [email-masked]; [email-masked]
主题: Re: [Rtg-yang-coord] issue :R01: route filters

Lada

> To: Anees Shaikh; Acee Lindem (acee); Lizhenbin; Susan Hares; Jeff 
> 收件人: Acee Lindem (acee); Lizhenbin; Susan Hares; Jeff Tantsura; 
> The bgp-operational module is largely unchanged -- the next release is 
> expected to contain a significant update.
>  
> currently augmented by the bgp-policy module for bgp-specific routing 
> policy options.
>  
> 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
> 
> >components for I2RS. It is better the Yang models for the policy 
> >should be defined in the I2RS WG instead of RTGWG.
> >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
> >
> >
> >
> >
> >
> >I am interested.  We having routing policy discussion in I2RS 
> >relating PBR and policy.  It needs to link to a base specification.
> >
> >Sue
> >
> >Behalf Of Jeff Tantsura
> >>>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.
> >>>
> >>>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.
> >>>
> >>>routing policies, and you want to introduce to vendor Y, 
> >>>translation of routing policies from language X to Y is a very complex work.
> >>>
> >>>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
> >>>
> >>>
> >>>
> >>>
> >>>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.
> >>>
> >>>> I think working of BGP YANG is a good opportunity to start 
> >>>>working on policy framework.
> >>>> 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.
> >>>>
> >>>>>>>>route filters proposed (deny-all or allow-all). As we know 
> >>>>>>>>some routing protocols require explicit permission to operate (example:
> >>>>>>>>EBGP).
> >>>>>>>>> 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
> >>>>>>>
> >>>> _________________________________________________________________
> >>>> ___ __ ___________________________________________________
> >>>>
> >>>> 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.
> >>>>
> >>>>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.
> >>>etant susceptibles d'alteration, Orange decline toute 
> >>>responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>>privileged information that may be protected by law; they should 
> >>>not be distributed, used or copied without authorisation.
> >>>etant susceptibles d'alteration, Orange decline toute 
> >>>responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> >>>
> >>>privileged information that may be protected by law; they should 
> >>>not be distributed, used or copied without authorisation.
> ___________________________________________________
>  
> 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.
>  
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
> ___________________________________________________
>  
> 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.
>  
> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 13 Jan 2015 12:38:01 +0100

> On 13 Jan 2015, at 11:48, Qin Wu <[email-masked]> wrote:
> 

Sure, that’s the way how to do it.

Lada

---

From: Anees Shaikh <[email-masked]>
Date: Wed, 14 Jan 2015 17:56:59 +0000

sorry for my late reply -- we don't use recursive groupings, but rather
references to named policy definitions to enable the policy subroutine
feature.

And we deliberately did not specify any sort of nesting depth because you
will find that it varies across major implementations -- some explicitly
limit to one, while others do not specify any limit.

In any case, nesting beyond one or two levels very quickly leads to overly
complex policies IMO.

thanks.
-- Anees

On Tue Jan 13 2015 at 2:24:32 AM Qin Wu <[email-masked]> 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?
>
>
>
> Regards!
>
> -Qin
>
> *发件人:* Rtg-yang-coord [mailto:[email-masked]] *代表 *
> [email-masked]
> *发送时间:* 2015年1月6日 18:26
> *收件人:* Anees Shaikh; Qin Wu
> *抄送:* [email-masked]
>
> *主题:* 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:[email-masked] <[email-masked]>]
> *Sent:* Monday, January 05, 2015 17:40
> *To:* LITKOWSKI Stephane SCE/IBNF; Qin Wu
> *Cc:* [email-masked]
> *Subject:* Re: [Rtg-yang-coord] issue :R01: route filters
>
>
>
> <[email-masked]>] *代表* Anees Shaikh
> *发送时间**:* 2014年12月26日 9:53
> *收件人**:* Acee Lindem (acee); Lizhenbin; Susan Hares; Jeff Tantsura;
> *抄送**:* [email-masked]; Dean Bogdanovic; Ladislav Lhotka
> *主**题**:* Re: [Rtg-yang-coord] 答复: issue :R01: route filters
>
>
>
>