Comments on draft-shaikh-rtgwg-policy-model

<stephane.litkowski@orange.com> Mon, 20 July 2015 11:35 UTC

Return-Path: <stephane.litkowski@orange.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C45611A1ADB for <rtgwg@ietfa.amsl.com>; Mon, 20 Jul 2015 04:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gy7jlspJH57 for <rtgwg@ietfa.amsl.com>; Mon, 20 Jul 2015 04:35:18 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A12D1A0366 for <rtgwg@ietf.org>; Mon, 20 Jul 2015 04:35:17 -0700 (PDT)
Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id CFC61374397 for <rtgwg@ietf.org>; Mon, 20 Jul 2015 13:35:15 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.41]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id AB4DDC8122 for <rtgwg@ietf.org>; Mon, 20 Jul 2015 13:35:15 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 13:35:15 +0200
From: <stephane.litkowski@orange.com>
To: "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Comments on draft-shaikh-rtgwg-policy-model
Thread-Topic: Comments on draft-shaikh-rtgwg-policy-model
Thread-Index: AdDC3mGR5ZGZB0pXRXeVs9QL62qf/A==
Date: Mon, 20 Jul 2015 11:35:14 +0000
Message-ID: <6148_1437392115_55ACDCF3_6148_2234_11_9E32478DFA9976438E7A22F69B08FF92166A0AC1@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF92166A0AC1OPEXCLILMA4corp_"; type="multipart/alternative"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.20.94516
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/xuoXjw5H76Mw6zGf_pIwCvxALOY>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2015 11:35:21 -0000

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: +33 2 23 28 49 83 <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: +33 6 37 86 97 52 <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>
stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>



_________________________________________________________________________________________________________________________

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.