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

From: <[email-masked]>
Date: Tue, 16 Dec 2014 12:13:41 +0000

Hi Lada,

I would be in favor of removing route-filters from the core routing model and let another "Route Policy" Yang model augments it in future.
Route policy definition in YANG will be a hard work and it would be better to restart from scratch rather than adding some design constraints from the beginning.

Regards,

Stephane

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Tuesday, November 25, 2014 14:12
To: [email-masked]
Subject: [Rtg-yang-coord] issue :R01: route filters

Hi,

this issue refers the YANG module "ietf-routing" contained in

http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-16

Please indicate your preference or add comments.

***** :R01: route filters
      In -16, route filters are defined as stubs with the assumption
      that real route filtering frameworks will be developed
      later. This could work provided that such frameworks can accept
      the control points for applying route filters as they are
      defined in -16, i.e. (i) between routing protocol instances and
      connected RIBs, and (ii) between RIBs.

****** Solution R01-1
       No change.

****** Solution R01-2
       Keep the stub route filters but change the control points.

****** Solution R01-3
       Remove route filters from the ietf-routing module. Future route
       filtering frameworks will define the control points and augment
       ietf-routing accordingly.

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 16 Dec 2014 14:12:27 +0100

> On 16 Dec 2014, at 13:13, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Lada,
> 

OK. It is also true that it won’t preclude anybody from defining a temporary solution before a standard one is ready.

Thanks, Lada

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 17 Dec 2014 06:03:31 +0000

I agree with Stephane.

Regards,
Jeff

> On Dec 16, 2014, at 4:13 AM, "[email-masked]" <[email-masked]> wrote:
> 
> Hi Lada,
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 17 Dec 2014 21:09:08 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 17 Dec 2014 22:49:47 +0100

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.

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 17 Dec 2014 22:07:31 +0000

Robert,

Your proposal is very sensible and I think this is the best option

Dean

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 17 Dec 2014 22:08:29 +0000

On Dec 17, 2014, at 4:09 PM, Dean Bogdanovic <[email-masked]> wrote:

> I'm in support of removing route filters from the routing cfg model.

Since I originally raised the issue, I’m definitely in favor of this. 

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

While the list and permit/deny semantics are similar, I don’t think it is a good idea to mix packet filtering and route filtering. We’ll have much cleaner models if we maintain this separation. IMO, this negates the advantage of reusing the list and permit/deny semantics. Consequently my vote would be for a separate route-prefix-list rather than mixing these things just to pick up the list semantics. 

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 17 Dec 2014 22:12:14 +0000

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

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 17 Dec 2014 22:14:42 +0000

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

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 17 Dec 2014 23:28:17 +0100

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.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 17 Dec 2014 22:51:58 +0000

> wait few years till YANG for policy spec is complete ?

The design of the routing policy model and the BGP module should precede in parallel. For BGP, at least in my opinion, there will be protocol specific policy. In fact, if we follow the majority of the deployed implementations, all the routing policy attach points could be in the routing protocol models.  

There are also implementations that support procedural policy. However, there is significant variance between implementations and these do not lend themselves nicely to YANG representation. Hence, the models representing these directly will most likely ending up being vendor specific. 

In short, this is not an easy problem but standardizing these permit/deny all route filters at arbitrary attach points doesn’t get us any closer to YANG routing policy.  

Thanks,
Acee

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 17 Dec 2014 22:56:31 +0000

Robert,

This is why we do standardization, isn¹t it? :)
I¹m quite sure ³some implementations² will not be fully compliant with the
formal YANG specifications to come and would have to be changed/enhanced.

Formal design of BGP protocol should be done independently, YANG work is
there to augment, not to interrupt.

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Date: Wednesday, December 17, 2014 at 2:28 PM
To: Jeff Tantsura <[email-masked]>
Cc: "Acee Lindem (acee)" <[email-masked]>, Dean Bogdanovic
<[email-masked]>, "[email-masked]" <[email-masked]>,
Stephane Litkowski <[email-masked]>, Ladislav Lhotka
<[email-masked]>
Subject: Re: [Rtg-yang-coord] issue :R01: route filters

>> Yes, exactly, Robert - the behavior you have described is an
>>implementation, not a formal specification.
>>
>> Regards,
>> Jeff
>>
>>> 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
>>>
>>>>>> 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
>>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Dec 2014 11:10:18 +0100

Hi Robert,

> we remove even those two primitive filters there can be impact to

Protocols can have an "enabled" switch as a part of their
configuration. Does it solve this issue?

Should the two primitive filters be needed before the routing policy
model gets done, I'd propose to have them in a separate module that
augments the "ietf-routing" module. This way, they could be replaced at
any time without affecting the rest of the routing model. This extra
module can be published either in the same document or in a new I-D.

Lada

---

From: t.petch <[email-masked]>
Date: Thu, 18 Dec 2014 10:03:20 +0000

----- Original Message -----
From: "Robert Raszuk" <[email-masked]>
To: "Jeff Tantsura" <[email-masked]>
Sent: Wednesday, December 17, 2014 10:28 PM

> will not be compatible with some implementations ?

Robert

It might be more accurate to say that the formal YANG specification will
not be compatible with any implementation!

The IETF does a grand job with protocols, what can be seen on whatever
connects two black boxes, and there are myriad such boxes that conform
to IETF RFC.  Configuring, the prime purpose of YANG models, is about
poking around inside the implementation and making changes thereto,
something a protocol has little to do with.

So as I have tracked the development of models, first with SMI and now
YANG, I see this issue getting larger, that we are trying to specify
something new and different for which there has been historically no
standard, except, perhaps, where implementers might use the BGP FSM as a
basis for their design.

Lada studied four router implementations before producing routing-cfg
and used their concepts to produce the model.  Cisco and Juniper
diverged widely, e.g. on RIB and FIB, which led to lengthy discussions
on the netmod list and a rough consensus (which I am not part of).

So it is quite likely that none of the four templates match routing-cfg
and no current implementation matches the YANG model.  Perhaps future
implementers will use a YANG model for their design and so in time,
there will be a convergence.

I think that this point needs to be in our thinking when producing YANG
models, that it should be possible to present the appearance over
NETCONF of a box that is structured in the manner of the model and to
implement a box which matches the YANG model (even if, so far, noone
ever has - and may be noone ever will)

Meanwhile, we should go on designing protocols (something we are rather
good at:-).

Tom Petch

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Dec 2014 12:00:38 +0100

> On 18 Dec 2014, at 11:03, t.petch <[email-masked]> wrote:
> 

Actually, I really studied only three implementations (Cisco IOS, JUNOS and BIRD), with occassional input from people familiar with other implementations. I tried to make sure that a mapping to each of the three implementations can be established, and I believe it is still the case if we limit ourselves to the relatively basic “core” data models that are being produced by the NETMOD WG.

However, Tom’s observation might well be true when it comes to more complicated stuff that really depends on the internals of a routing system implementation. I raised some concerns and questions in my review of the OSPF data model:

http://www.ietf.org/mail-archive/web/netmod/current/msg11029.html

Lada

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 18 Dec 2014 15:27:15 +0100

Tom, Ladislav,

Many thx for your insight !

r.

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 18 Dec 2014 15:33:47 +0000

>not be compatible with any implementation!

I believe the model (as proposed) is aligned with BIRD.

Thanks,
Acee

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Dec 2014 16:59:05 +0100

> On 18 Dec 2014, at 16:33, Acee Lindem (acee) <[email-masked]> wrote:
> 
> 
> 

Not really. For instance, BIRD has no notion of routing instances or multiple address families, and it uses a special pseudo-protocol ‘pipe’ for passing routes between routing tables. I’d say the model is closer to JUNOS than BIRD.

And as for IOS, I wrote an XSLT stylesheet that was able to transform any YANG configuration comprising the modules ietf-interfaces, ietf-ip, ietf-system, ietf-routing, and ietf-ipv[46]-unicast-routing into IOS configuration:

https://gitlab.labs.nic.cz/labs/yang-tools/tree/master/data-models/xslt/cisco-ios

I haven’t updated it for some time so that it probably won’t work now due to the changes to the modules that happened in the mean time, but I am convinced it can still be done.

Note also that I wasn’t affiliated with CZ.NIC (= BIRD maintainer) at the time when the routing module was designed.

Lada

---

From: <[email-masked]>
Date: Fri, 19 Dec 2014 10:03:51 +0000

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:
>>>> protocols require explicit permission to operate (example: EBGP). 
>>>> If we remove even those two primitive filters there can be impact 
>>>> to other components.
>>>>
>>>> significant diversity of policy languages across all 
>>>> implementations today.
>>>>

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Dec 2014 11:10:12 +0100

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.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 19 Dec 2014 11:38:01 +0100

> On 19 Dec 2014, at 11:10, Robert Raszuk <[email-masked]> wrote:
> 
> Hi Stephane,
> 

Right, configuration of route filters is an area where various implementations widely differ. That’s why the route filter in ietf-routing has the “type” parameter so that alternative filtering frameworks could be used.

> Is this really where we want to go with this entire effort ?

My suggestion would be that each vendor create their own “legacy” model(s) and the new IETF data model would be recommended for new implementations.

Lada

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Dec 2014 11:53:49 +0100

Ladislav,

But vendors live and gain by being better then their immediate
competition. Both in routing protocols features as well as policy
flexibility.

For them what you call "legacy" is the secret sauce they want to keep
for years to come. I am afraid attempt to place them under common
denominator will just not work from business point of view.

Otherwise how they are going to make money and differentiate
themselves from open source control plane efforts and growing market
of ODM/OCP based hardware ?

Cheers,
R.

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 19 Dec 2014 12:16:34 +0100

> On 19 Dec 2014, at 11:53, Robert Raszuk <[email-masked]> wrote:
> 
> Ladislav,
> 

Of course, that’s everybody’s choice. I didn’t mean a common denominator though but rather a simple and powerful data model developed from scratch that will be arguably better than the existing options.

> of ODM/OCP based hardware ?

Unix history shows that it can also be an open source alternative that survives.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 19 Dec 2014 12:17:57 +0100 (CET)

Hi,

It is expected that vendors create their own YANG modules that extend
the standard models with whatever features the vendors have.  By
having a common set of standard models, there will be commonality in
the structure and how things are named, which helps operators without
restricting vendors.

In the specific case of routing policy, I think what Lada says is that
there can be vendor-specific policy models in addition to the standard
model.  The standard is the "baseline", but operators can choose to
use the vendor-specific model if it provides additional benfits.

/martin

---

From: Giles Heron <[email-masked]>
Date: Fri, 19 Dec 2014 11:58:11 +0000

But isn't there a fairly common case where multiple vendors have a common "knob" (e.g. because a big carrier has asked all of them to add it), but where that knob isn't documented in an RFC anywhere?

In that instance I'd presume we want that knob to be part of the IETF standard model - or at least part of a common augment on a github somewhere - rather than each vendor defining their own potentially incompatible augment.

Giles

---

From: <[email-masked]>
Date: Fri, 19 Dec 2014 11:58:40 +0000

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.

Best,
r.

On Fri, Dec 19, 2014 at 11:03 AM,  <[email-masked]> wrote:
> Cc: Acee Lindem (acee); Dean Bogdanovic; [email-masked]; 
> LITKOWSKI Stephane SCE/IBNF; Ladislav Lhotka
>>>>> 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).
> ______________________________________________________________________
> ___________________________________________________
>
> 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.

---

From: <[email-masked]>
Date: Fri, 19 Dec 2014 12:00:47 +0000

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)

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,

Best,
r.

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: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 19 Dec 2014 16:12:24 +0000

I would like to be involved.
Thanks,
Acee 

On 12/19/14, 7:00 AM, "[email-masked]"
<[email-masked]> wrote:

>- 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. 
>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.
>
>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.
>
>> 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
>>
>>
>>>>between RIBs? Note that it isn¹t like we have a set of approved
>> 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.
>__________________________________________________________________________
>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.
>__________________________________________________________________________
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 19 Dec 2014 16:18:59 +0000

I would like to be involved as well :-)

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 19 Dec 2014 17:27:25 +0100

Looks like a dream crew already ... +1 :)

r.

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 19 Dec 2014 21:35:56 +0000

I’d like to be involved, as well as giving it a home in rtgwg

Cheers,
Jeff

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 19 Dec 2014 18:09:04 -0500

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

Cheers,
Jeff

-----Original Message-----

>>- 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.
>>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 
>>granularity of the parameter). So I think that creating usable 
>>standard model can work. The remaining x% can be addressed by vendor
extensions.
>>extension or feature standardized in IETF, it will be up to customers 
>>to request their vendors for implementations.
>>
>>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.
>>
>>prone a consensus on strong adoption of standard YANG models rather 
>>than vendor specific only.
>>
>>
>>Stephane
>> 
>> 
>>
>>
>>>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
>>>
>>>
>>> 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.
>>>
>>>>>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
>>>>>
>>>>>>> If we remove even those two primitive filters there can be 
>>>>>>>impact  to other components.
>>>>>>>
>>>>>>> expect this to be a very interesting and involved work 
>>>>>>> considering significant diversity of policy languages across all 
>>>>>>> implementations today.
>>>>>>>
>>>>>>>>which also ACL model belongs too. Actually, I would argue that 
>>>>>>>>the current ACL model is very suitable for route filters.
>>>>>>>>
>>>>>>>> Dean
>>>>>>
>>> ____________________________________________________________________
>>> __ ___________________________________________________
>>>
>>>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.
>>>
>>
>>___
>>_
>>privileged information that may be protected by law; they should not 
>>be distributed, used or copied without authorisation.
>>___
>>_
>>privileged information that may be protected by law; they should not 
>>be distributed, used or copied without authorisation.

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 20 Dec 2014 10:05:57 +0100

> On 19 Dec 2014, at 13:00, [email-masked] wrote:
> 

I am interested.

Lada

---

From: wangzitao <[email-masked]>
Date: Thu, 25 Dec 2014 09:06:35 +0000

I am interested.

-Michael

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

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,

Best,
r.

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Dec 2014 10:53:55 +0000

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

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

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,

Best,
r.

---

From: Qin Wu <[email-masked]>
Date: Thu, 25 Dec 2014 11:12:32 +0000

Jeff:
Isn't this topic subsumed into I2RS?
What am I missing?

Regards!
-Qin
-----邮件原件-----
发件人: Rtg-yang-coord [mailto:[email-masked]] 代表 Jeff Tantsura
发送时间: 2014年12月20日 5:36
收件人: Acee Lindem (acee); [email-masked]; Robert Raszuk
抄送: [email-masked]; Dean Bogdanovic; Ladislav Lhotka
主题: Re: [Rtg-yang-coord] issue :R01: route filters

Cheers,
Jeff

-----Original Message-----

>>standard model can work. The remaining x% can be addressed by vendor extensions.
>>

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 25 Dec 2014 12:17:58 +0100

Qin,

draft-atlas-i2rs-policy-framework-00 can be helpful to this work.

The other two drafts on PBR are quite irrelevant. We are not talking
about PBR here at all. It is just one specific application of data
plane policy.

Our effort first is to define YANG model for control plane policy.

Best,
r.

---

From: Lizhenbin <[email-masked]>
Date: Thu, 25 Dec 2014 13:19:36 +0000

Hi Stephen,
I wonder how to say I am interested :) In fact, when we preprare the Yang models for different routing protocols and MPLS protocols, it is found the Yang models for the standard route policy is inevitable though we are also aware that defining the Yang models for the routing policy will be more difficult than the Yang models for the protocols. In order to push the work, I have organized one internal team to define the Yang models for the routing policy and it will be published soon. Now it seems there are so many people that would like to involve in the work, could we work out the possible way before we publish 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:

Sue

-----Original Message-----

Cheers,
Jeff

-----Original Message-----

extensions.

---

From: Lizhenbin <[email-masked]>
Date: Thu, 25 Dec 2014 13:33:08 +0000

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

Stephen:

Sue

-----Original Message-----

Cheers,
Jeff

-----Original Message-----

extensions.

---

From: wangzitao <[email-masked]>
Date: Fri, 26 Dec 2014 02:34:45 +0000

Hi, Robert:
What about the basic network policy draft in I2RS?
https://tools.ietf.org/html/draft-hares-i2rs-bnp-info-model-01
the basic network policy model proposed in the above draft is used
as the basis to build PBR model, I believe it also can be applied to control plane policy model.
Section 5 of this draft gives a BGP policy example.

BR
-Michael
-----邮件原件-----
发件人: Rtg-yang-coord [mailto:[email-masked]] 代表 Robert Raszuk
发送时间: 2014年12月25日 19:18
收件人: Qin Wu
抄送: [email-masked]; [email-masked]; Dean Bogdanovic; Jeff Tantsura; Ladislav Lhotka; David Sinicrope; Acee Lindem (acee)
主题: Re: [Rtg-yang-coord] issue :R01: route filters

Qin,

The other two drafts on PBR are quite irrelevant. We are not talking about PBR here at all. It is just one specific application of data plane policy.

Best,
r.

On Thu, Dec 25, 2014 at 12:12 PM, Qin Wu <[email-masked]> wrote:
>>>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: "Acee Lindem (acee)" <[email-masked]>
Date: Fri, 26 Dec 2014 21:52:45 +0000

Hi Michael, 

I think it would be great for the providers to give us their view on how
routing policy should be modeled before anyone goes down to the low level
YANG definitions. I will review the info model in the referenced draft as
well. 

Thanks,
Acee 

On 12/25/14, 9:34 PM, "wangzitao" <[email-masked]> wrote:

>抄送: [email-masked]; [email-masked]; Dean
>Bogdanovic; Jeff Tantsura; Ladislav Lhotka; David Sinicrope; Acee Lindem
>(acee)
>about PBR here at all. It is just one specific application of data plane
>policy.
>

---

From: wangzitao <[email-masked]>
Date: Sat, 27 Dec 2014 06:41:57 +0000

Hi Acee,

I thought bnp info model draft has already looked at high level YANG definition, maybe I am wrong, but I agree with you we should listen to provider's view.

BR
-Michael
-----邮件原件-----
发件人: Acee Lindem (acee) [mailto:[email-masked]] 
发送时间: 2014年12月27日 5:53
收件人: wangzitao; Robert Raszuk
抄送: [email-masked]
主题: Re: [Rtg-yang-coord] issue :R01: route filters

Hi Michael, 

I think it would be great for the providers to give us their view on how routing policy should be modeled before anyone goes down to the low level YANG definitions. I will review the info model in the referenced draft as well. 

Thanks,
Acee 

On 12/25/14, 9:34 PM, "wangzitao" <[email-masked]> wrote:

>the basic network policy model proposed in the above draft is used as 
>the basis to build PBR model, I believe it also can be applied to 
>control plane policy 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.
>>>>
>>>>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.
>>>>
>>>>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
>>>>
>>>>
>>>>
>>>>
>>>>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.
>>>>
>>>>>>>> On Dec 17, 2014, at 5:07 PM, Dean Bogdanovic 
>>>>>>>><[email-masked]>
>>>>>>>>wrote:
>>>>>>>>
>>>>>>>> Robert,
>>>>>>>>
>>>>>>>>>>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
>>>>>>>>
>>>>> __________________________________________________________________
>>>>> _ _ __ ___________________________________________________
>>>>>
>>>>>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.