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

<> Mon, 20 July 2015 12:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 67D681A21BD for <>; Mon, 20 Jul 2015 05:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EkeIf7Vaz8WA for <>; Mon, 20 Jul 2015 05:21:13 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B03D11A21B4 for <>; Mon, 20 Jul 2015 05:21:12 -0700 (PDT)
Received: from (unknown [xx.xx.xx.3]) by (ESMTP service) with ESMTP id 381BB26421C; Mon, 20 Jul 2015 14:21:11 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 11CEF4C125; Mon, 20 Jul 2015 14:21:11 +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 14:21:10 +0200
From: <>
To: Jeffrey Haas <>
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model
Thread-Topic: Comments on draft-shaikh-rtgwg-policy-model
Thread-Index: AdDC3mGR5ZGZB0pXRXeVs9QL62qf/P//5TuA///X+EA=
Date: Mon, 20 Jul 2015 12:21:09 +0000
Message-ID: <18735_1437394871_55ACE7B7_18735_2268_1_9E32478DFA9976438E7A22F69B08FF92166A0BB9@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <6148_1437392115_55ACDCF3_6148_2234_11_9E32478DFA9976438E7A22F69B08FF92166A0AC1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166A0BB9OPEXCLILMA4corp_"
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2015.7.20.115415
Archived-At: <>
Cc: "" <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2015 12:21:15 -0000

Hi Jeff,

Inline comments

From: Jeffrey Haas []
Sent: Monday, July 20, 2015 13:47
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

On Jul 20, 2015, at 1:35 PM, <<>> <<>> wrote:

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

I believe we do wish to keep this field used for IGP route tagging since that's a protocol component.
[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.

(Fascinating issue, while researching ISIS implementations I found that the protocol permits 64bit tagging, but didn't find anyone that implemented them.)
[SLI] ☺ we have it in IS-IS yang model , tag64 if I remember correctly.

I do realize that there is also a need to do general route mark-up so that policy engines can operate off of that.  I know that for certain route types, the "tag" field might be able to be used for this purpose; e.g it has no semantics in a given BGP implementation unless the route is redistributed in the IGP.  (And I'm not even sure that field survives export, I'd have to check the code.)

Perhaps more appropriate would be to have a new mark-up field, name TBD, to cover this purpose.  It could then be implemented as appropriate for a given route type and vendor implementation?

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