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

"Acee Lindem (acee)" <> Sun, 26 July 2015 17:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5C17E1ACCE1 for <>; Sun, 26 Jul 2015 10:49:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 47k-oyhT5NqF for <>; Sun, 26 Jul 2015 10:49:31 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02F521ACCE4 for <>; Sun, 26 Jul 2015 10:49:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=21651; q=dns/txt; s=iport; t=1437932971; x=1439142571; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qraVtd44j1NqTSttYY1c46fTgivF5JLnhsPhnL2toaQ=; b=MhnnsTP706anIY8YB+z/3NQbGMJVFF7KcZnn+EPqJvBweQUajtI2yBa3 6DwzG+0duEeBCqh6rtPv4aLUr/mXnyo2k7Uc/CXMhqQfDicVcnrrIAioS 6rsJFacGeCgVQFjvOsERx/8ezFoqb0AsxqDcPA8LqwN66o4x13MHQycmp w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.15,547,1432598400"; d="scan'208,217"; a="15147402"
Received: from ([]) by with ESMTP; 26 Jul 2015 17:49:30 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id t6QHnTFA012993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 26 Jul 2015 17:49:29 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Sun, 26 Jul 2015 12:49:29 -0500
From: "Acee Lindem (acee)" <>
To: "" <>, "Rob Shakir" <>, Jon Mitchell <>
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model
Thread-Topic: Comments on draft-shaikh-rtgwg-policy-model
Date: Sun, 26 Jul 2015 17:49:28 +0000
Message-ID: <>
References: <> <18735_1437394871_55ACE7B7_18735_2268_1_9E32478DFA9976438E7A22F69B08FF92166A0BB9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <2188_1437400730_55ACFE9A_2188_4362_1_9E32478DFA9976438E7A22F69B08FF92166A0CC7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <26470_1437402600_55AD05E8_26470_6250_3_9E32478DFA9976438E7A22F69B08FF92166A0D94@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <etPan.55ae5784.52673c74.36f@corretto.local> <23963_1437493971_55AE6AD3_23963_745_1_9E32478DFA9976438E7A22F69B08FF92166A33EC@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <etPan.55ae8fbf.2ac767e3.36f@corretto.local> <18774_1437550328_55AF46F8_18774_5612_26_9E32478DFA9976438E7A22F69B08FF92166A3667@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <> <etPan.55af51be.69dfac96.36f@corretto.local> <9439_1437568985_55AF8FD9_9439_5180_1_9E32478DFA9976438E7A22F69B08FF92166A398C@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
In-Reply-To: <9439_1437568985_55AF8FD9_9439_5180_1_9E32478DFA9976438E7A22F69B08FF92166A398C@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_D1D97D0929830aceeciscocom_"
MIME-Version: 1.0
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: Sun, 26 Jul 2015 17:49:35 -0000

I’ve read all the E-mails in this thread and I think I agree with Stephane in that a route has one or more tags that are advertised within the protocols and are installed into the appropriate RIB. This is the most straight forward and useful application of tags.

I think having two types of tags for routes (local and IGP) will only add complexity and confusion.


From: rtgwg <<>> on behalf of Stephane Litkowski <<>>
Date: Wednesday, July 22, 2015 at 2:43 PM
To: Rob Shakir <<>>, Jon Mitchell <<>>
Cc: Routing WG <<>>
Subject: RE: Comments on draft-shaikh-rtgwg-policy-model

I have no issue to have two tags as long as I can have dynamic copy of the one the other (copying local tag to protocol tag, or reverse, or a protocol tag between two different protocols …).

From: Rob Shakir []
Sent: Wednesday, July 22, 2015 10:18
To: Jon Mitchell; LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas;<>
Subject: Re: Comments on draft-shaikh-rtgwg-policy-model

The way that we have tried to approach these things with the OpenConfig initiated models is “what is the way that we use this feature” - and then try and design the way that the model works around this.

To me, it seems like I want to be able to explicitly control whether something that I am using as a local route marker (‘colour’) is propagated to any of my neighbours via a particular routing protocol - otherwise, it takes on other semantics that I might not intend it to do.

In the local-routing [0] module, we use ‘tag’ as a protocol-agnostic way to mark particular routes — and then when these locally generated routes are imported into other protocols, then attributes for those protocols can be set (e.g., BGP community etc.). It strikes me that we should have something similar in each protocol export policy that says match on the local ‘tag’/‘colour’ and set protocol-tag value X (or even a switch that says ‘propagate tag’ assuming that the colour type can be mapped to the protocol tag type).

I’d really like to separate local ‘tag’/‘colour’ from ‘tag’ within any particular protocol.



On 22 July 2015 at 08:39:55, Jon Mitchell (<>) wrote:
On 22/07/15 07:32 +0000,<> wrote:
> Hi Rob,
> Agree with the case you presented, IMO, we may provide some guidance to implementation on the behavior to use when a local-tag is translated to a protocol-tag and translation is not possible due to protocol-tag constraint (for example “do not copy tag”).

I'd also point out that some implementations (even from the same
vendor!) have different behavior on whether to default copy up from
lcoal tag to protocol tag even when it is possible when redistribution
is configured.



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.