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

Jeffrey Haas <> Mon, 20 July 2015 11:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 02F161A6F2A for <>; Mon, 20 Jul 2015 04:47:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.577
X-Spam-Status: No, score=-1.577 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k57Y7kicIzPd for <>; Mon, 20 Jul 2015 04:47:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 852E11A6EE7 for <>; Mon, 20 Jul 2015 04:46:55 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 51C9C1E36F; Mon, 20 Jul 2015 07:48:53 -0400 (EDT)
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_E0758223-6BF1-408E-887D-E03F304D4F2A"
From: Jeffrey Haas <>
In-Reply-To: <6148_1437392115_55ACDCF3_6148_2234_11_9E32478DFA9976438E7A22F69B08FF92166A0AC1@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Date: Mon, 20 Jul 2015 13:46:49 +0200
Message-Id: <>
References: <6148_1437392115_55ACDCF3_6148_2234_11_9E32478DFA9976438E7A22F69B08FF92166A0AC1@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
To: "" <>
X-Mailer: Apple Mail (2.2102)
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 11:47:17 -0000

> 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.  
(Fascinating issue, while researching ISIS implementations I found that the protocol permits 64bit tagging, but didn't find anyone that implemented them.)

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