RE: Comments on draft-shaikh-rtgwg-policy-model

<stephane.litkowski@orange.com> Mon, 20 July 2015 13:58 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 419E51A87B9 for <rtgwg@ietfa.amsl.com>; Mon, 20 Jul 2015 06:58:54 -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 LsEuNK8B9elZ for <rtgwg@ietfa.amsl.com>; Mon, 20 Jul 2015 06:58:52 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FBB81A8893 for <rtgwg@ietf.org>; Mon, 20 Jul 2015 06:58:51 -0700 (PDT)
Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 20464190675; Mon, 20 Jul 2015 15:58:50 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.66]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id EC7B918010D; Mon, 20 Jul 2015 15:58:49 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0235.001; Mon, 20 Jul 2015 15:58:40 +0200
From: <stephane.litkowski@orange.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model
Thread-Topic: Comments on draft-shaikh-rtgwg-policy-model
Thread-Index: AdDC3mGR5ZGZB0pXRXeVs9QL62qf/P//5TuA///X+ECAADgKAP//yjOw
Date: Mon, 20 Jul 2015 13:58:39 +0000
Message-ID: <2188_1437400730_55ACFE9A_2188_4362_1_9E32478DFA9976438E7A22F69B08FF92166A0CC7@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <6148_1437392115_55ACDCF3_6148_2234_11_9E32478DFA9976438E7A22F69B08FF92166A0AC1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <E4CCDE37-90A5-4ED5-8E85-3DAD595347C0@pfrc.org> <18735_1437394871_55ACE7B7_18735_2268_1_9E32478DFA9976438E7A22F69B08FF92166A0BB9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <AE597A9E-B8D5-4E7B-A292-6E1671BD5862@pfrc.org>
In-Reply-To: <AE597A9E-B8D5-4E7B-A292-6E1671BD5862@pfrc.org>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.3]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166A0CC7OPEXCLILMA4corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.20.115415
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/_rHOIE4A_PTdq8mYpnjEDiQnnJY>
Cc: "rtgwg@ietf.org" <rtgwg@ietf.org>
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 13:58:54 -0000

Right, each protocol has its own constraint, but do you think creating an additional generic marker will solve those constraints ? We would expect to be able to have the generic marker to protocol tag and also two protocol tags with different constraints to interact between each other (I mean for example, learning a RIP tag and copying it to ISIS or OSPF).


From: Jeffrey Haas [mailto:jhaas@pfrc.org]
Sent: Monday, July 20, 2015 14:44
To: LITKOWSKI Stephane SCE/IBNF
Cc: rtgwg@ietf.org
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

Stephane,

On Jul 20, 2015, at 2:21 PM, <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>> <stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com>> wrote:

[SLI] Do we really need to differentiate from a policy point of view ? from an import policy perspective, matching a tag, means learning the tag value available in the protocol (if available) and when the route ins inserted into RIB the tag value is copied from the protocol value if not overrided by import policy action; from an export policy perspective (talking about export from rib to protocol), matching a tag means matching the tag value in the RIB (which may come from protocol or not),  setting a tag means fill the protocol field if available. From a RIB point of view, the tag associated with the route is protocol agnostic, even if the protocol does not support tags in encoding you may associate a local tag for policy processing.

Having two types of tags is also possible : protocol-tag and local-tag but I see more complexity and do not see more flexibility : but maybe there is some use case that I do not see.

The messy detail with this attribute is that while it's useful as a generic policy element, in specific protocol context it needs to have differing constraints.  OSPF has one set of constraints, RIP a slightly different one (zero is reserved), and ISIS has different sizes with some option for one or two tags plus the 64-bit tag previously discussed.

This set of context specific constraints probably removes some level of the flexibility that you'd want for it to be a generic marker - unless you can live within the least common denominator.

-- Jeff


_________________________________________________________________________________________________________________________

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.