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

<stephane.litkowski@orange.com> Wed, 22 July 2015 12:43 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 E1B321A89A0 for <rtgwg@ietfa.amsl.com>; Wed, 22 Jul 2015 05:43:09 -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 h2w-H4LNZSZn for <rtgwg@ietfa.amsl.com>; Wed, 22 Jul 2015 05:43:07 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E317E1B3295 for <rtgwg@ietf.org>; Wed, 22 Jul 2015 05:43:06 -0700 (PDT)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 2B004324842; Wed, 22 Jul 2015 14:43:05 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 05D154C069; Wed, 22 Jul 2015 14:43:05 +0200 (CEST)
Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 14:43:04 +0200
From: stephane.litkowski@orange.com
To: Rob Shakir <rjs@rob.sh>, Jon Mitchell <jrmitche@puck.nether.net>
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//yjOwgABMbAD//9f34AA4Lt0A///IZ4D//4VegP/+D11A//w9noD/+HB0AP/wddUg
Date: Wed, 22 Jul 2015 12:43:03 +0000
Message-ID: <9439_1437568985_55AF8FD9_9439_5180_1_9E32478DFA9976438E7A22F69B08FF92166A398C@OPEXCLILMA4.corporate.adroot.infra.ftgroup>
References: <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> <2188_1437400730_55ACFE9A_2188_4362_1_9E32478DFA9976438E7A22F69B08FF92166A0CC7@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <23933303-B805-495D-AF0E-9305AED39F0A@pfrc.org> <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> <20150722073931.GB30425@puck.nether.net> <etPan.55af51be.69dfac96.36f@corretto.local>
In-Reply-To: <etPan.55af51be.69dfac96.36f@corretto.local>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166A398COPEXCLILMA4corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.22.121517
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/HznSf8x7CK2tWXR-6ozj04bLkSo>
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: Wed, 22 Jul 2015 12:43:10 -0000

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 [mailto:rjs@rob.sh]
Sent: Wednesday, July 22, 2015 10:18
To: Jon Mitchell; LITKOWSKI Stephane SCE/IBNF
Cc: Jeffrey Haas; rtgwg@ietf.org
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.

Cheers,
r.

[0]: https://github.com/YangModels/yang/blob/master/experimental/openconfig/local-routing/local-routing.yang


On 22 July 2015 at 08:39:55, Jon Mitchell (jrmitche@puck.nether.net<mailto:jrmitche@puck.nether.net>) wrote:
On 22/07/15 07:32 +0000, stephane.litkowski@orange.com<mailto:stephane.litkowski@orange.com> 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.

-Jon

_________________________________________________________________________________________________________________________

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.