Comments on draft-shaikh-rtgwg-policy-model

[<[e-mail]>]

Hi,

As pointed this morning during the WG session :

-          We need to clarify (asap if possible) the boundary between this policy model and what should be defined in protocol models to extend the policy. In the current version, it looks like a mix of having part of IGP defined in the generic policy framework and so expecting some other extensions in IGP models. For BGP, all is within BGP. My proposal would be to let all the protocol extensions to be in protocol models, this includes :

o   Protocol specific matching

o   Protocol specific actions

o   Install-protocol identity for that protocol => so need to remove the existing ones for ISIS, OSPF, BGP in the current version.

-          Regarding tags, as pointed today, I would like to have "tag" to be a generic local identifier rather than pointing only to IS-IS and OSPF. Any route within a RIB may have a local tag (this local tag can be learned from the routing protocol or set by configuration or policy). So setting a tag does not refer to any igp-action.

-          Also regarding the "igp-action" container, I'm not in favor of having separate containers for igp-actions, bgp-actions and generic-actions. Two possibilities :

o   Each protocol creates a container (e.g. isis-actions, ospf-actions ...) which augments the action container. Isis-actions and ospf-actions may be different (for example in setting route-type or metric type ...)

o   Just having the "actions" container and put all the actions here whatever the applicable protocol.

o   Similar approach to be taken for protocol specific conditions

-          I would be in favor in adding routing table matching condition and a way to select also a destination routing table. E.g. , I use an import policy to force a routing protocol to insert routes in a specific routing table rather than the default one. Or I want to authorize routes from multiple routing tables to be exported to a particular protocol.





Best Regards,

[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE
Orange Expert Future Networks
phone: [phone] <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
mobile: [phone] <https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
[e-mail]<mailto:[e-mail]>



_________________________________________________________________________________________________________________________

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.