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

Jeffrey Haas <> Mon, 20 July 2015 12:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D79311A8734 for <>; Mon, 20 Jul 2015 05:44:12 -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 LBQHfgFmJ0Ge for <>; Mon, 20 Jul 2015 05:44:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB7A21A700C for <>; Mon, 20 Jul 2015 05:44:11 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 2CA0F1E36F; Mon, 20 Jul 2015 08:46:09 -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=_AA23CBE3-61AA-499A-8182-E172A194A5B8"
From: Jeffrey Haas <>
In-Reply-To: <18735_1437394871_55ACE7B7_18735_2268_1_9E32478DFA9976438E7A22F69B08FF92166A0BB9@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Date: Mon, 20 Jul 2015 14:44:06 +0200
Message-Id: <>
References: <6148_1437392115_55ACDCF3_6148_2234_11_9E32478DFA9976438E7A22F69B08FF92166A0AC1@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <18735_1437394871_55ACE7B7_18735_2268_1_9E32478DFA9976438E7A22F69B08FF92166A0BB9@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 12:44:13 -0000


> On Jul 20, 2015, at 2:21 PM, <> <> 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