Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

"Alvaro Retana (aretana)" <aretana@cisco.com> Mon, 19 October 2015 12:39 UTC

Return-Path: <aretana@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F135D1A1A45; Mon, 19 Oct 2015 05:39:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CWlvJinWYHq; Mon, 19 Oct 2015 05:39:36 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5144E1A1A5B; Mon, 19 Oct 2015 05:39:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5924; q=dns/txt; s=iport; t=1445258376; x=1446467976; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D96dxE6Y0bS91kTuuwUhxfwrFX/gzXmRaH0IdiwR4WA=; b=mSBxBW5qODJDOCcByrI3orDBC9OscGJSkBqByQpDf9pNn6gPqVCyUW+V z6USkajbrv/RMmGMmwrockqLa/sJoMuRiUbxB42uRCVnhgCLCBmsVoJzU n1R8OtoOTN73M30fdTCOkS2j8ur2cqnxjxDT4ril+FQvNR9BgIbKpfDbL 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0D8AQD04yRW/40NJK1egzaBQwa5Z4QhAQ2BWoYeAoE2OBQBAQEBAQEBgQqELgEBBDo/EAIBCDYQMiUCBAENBYgwwxsBAQEBAQEBAQEBAQEBAQEBAQEBAQEYhncBhH2ENVgHhC4BBIc+inQog0kBjRyBWJZRg24BHwEBQoJEgT9yhB9CgQYBAQE
X-IronPort-AV: E=Sophos;i="5.17,701,1437436800"; d="scan'208";a="38934375"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-6.cisco.com with ESMTP; 19 Oct 2015 12:39:35 +0000
Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t9JCdZMZ002514 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2015 12:39:35 GMT
Received: from xch-aln-002.cisco.com (173.36.7.12) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 19 Oct 2015 07:39:17 -0500
Received: from xch-aln-002.cisco.com ([173.36.7.12]) by XCH-ALN-002.cisco.com ([173.36.7.12]) with mapi id 15.00.1104.000; Mon, 19 Oct 2015 07:39:17 -0500
From: "Alvaro Retana (aretana)" <aretana@cisco.com>
To: Shraddha Hegde <shraddha@juniper.net>, The IESG <iesg@ietf.org>
Thread-Topic: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)
Thread-Index: AQHRBcJuCumG1ZA/D0Cj5vEpcyU0Zp5sUYCAgAAuTQCAAbA8AP//5uGAgAR034CAAE/YAA==
Date: Mon, 19 Oct 2015 12:39:17 +0000
Message-ID: <D24A524F.DE641%aretana@cisco.com>
References: <20151013142127.29680.19611.idtracker@ietfa.amsl.com> <BY1PR0501MB1381AA752314C8677284A2F5D53E0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D244F4BA.DB9E8%aretana@cisco.com> <BY1PR0501MB1381A540ECC4E6F62651BF6ED53D0@BY1PR0501MB1381.namprd05.prod.outlook.com> <D2464C12.DBDFA%aretana@cisco.com> <CY1PR0501MB1385D3651FECEAC0520B9B8AD53A0@CY1PR0501MB1385.namprd05.prod.outlook.com>
In-Reply-To: <CY1PR0501MB1385D3651FECEAC0520B9B8AD53A0@CY1PR0501MB1385.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.117.15.3]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <9E209B81A1E8944CBB2A8CE7F83C0EF4@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/GbVVv33yuBnd7NjPSsIcgUoxrjE>
Cc: "draft-ietf-ospf-node-admin-tag.ad@ietf.org" <draft-ietf-ospf-node-admin-tag.ad@ietf.org>, "ospf@ietf.org" <ospf@ietf.org>, "draft-ietf-ospf-node-admin-tag.shepherd@ietf.org" <draft-ietf-ospf-node-admin-tag.shepherd@ietf.org>, "draft-ietf-ospf-node-admin-tag@ietf.org" <draft-ietf-ospf-node-admin-tag@ietf.org>, "ospf-chairs@ietf.org" <ospf-chairs@ietf.org>
Subject: Re: [OSPF] Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: The Official IETF OSPG WG Mailing List <ospf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ospf>, <mailto:ospf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ospf/>
List-Post: <mailto:ospf@ietf.org>
List-Help: <mailto:ospf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ospf>, <mailto:ospf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Oct 2015 12:39:40 -0000

On 10/18/15, 11:53 PM, "Shraddha Hegde" <shraddha@juniper.net> wrote:

Shraddha:


Hi!

I'm either completely missing the point, not explaining myself correctly,
or both.  We seem to be going around in circles.. :-(

I'm going to clear the DISCUSS.. I trust the responsible AD and hope that
the WG had the appropriate discussions.  There are still some comments
below.

Alvaro.

. . .
>
>From section 2 (updated text): "The choice of what scope at which to
>flood the group tags is a matter of local policy."  And form the new
>3.2.1: "The meaning of a per-node administrative tag is defined by the
>network local policy and is controlled via the configuration."
>Apparently not. :-(
>
>BTW, I noticed that in -08 you also added:
>
>   ... If a node
>   administrative tag is received in different scopes, the conflicting
>   tag SHOULD not be used and this situation SHOULD be logged as an
>   error including the tag with conflicting scopes and the
>   originator(s).
>
>
>[I know this was put in to answer the SecDir review related to what
>should be done if the same value was received with different flooding
>scopes.]
>
>Which is the "conflicting tag"?  Does it mean that for all scopes that
>specific value is not to be used?
>From section 2 (updated text): "The choice of what scope at which to
>flood the group tags is a matter of local policy."  And form the new
>3.2.1: "The meaning of a per-node administrative tag is defined by the
>network local policy and is controlled via the configuration."
>Apparently not. :-(
>
>BTW, I noticed that in -08 you also added:
>
>   ... If a node
>   administrative tag is received in different scopes, the conflicting
>   tag SHOULD not be used and this situation SHOULD be logged as an
>   error including the tag with conflicting scopes and the
>   originator(s).
>
>
>[I know this was put in to answer the SecDir review related to what
>should be done if the same value was received with different flooding
>scopes.]
>
>Which is the "conflicting tag"?  Does it mean that for all scopes that
>specific value is not to be used?
>
><Shraddha> Tags are associated with nodes which advertise them. There is
>no need to associate tags with scopes for any policy action. If an
>operator has any such usecase new tags can be associated with such a
>use-case.
>
>
>If so, what about policies in which the operator is looking for two (or
>maybe more) tags to be present to take an action?
>
><Shraddha> The issue being described here is about same tag appearing in
>different scopes on a non-ABR. It's perfectly valid to associate multiple
>tags with a node.

If the same tag value is flooded with multiple scopes, then it will be
declared conflicting (for all scopes).  If there are policies that are
dependent on those tags then they won't be applied -- including policies
that rely on more than one tag being present (including the one declared
conflicting, of course).  The point of that question was to point out that
by invalidating a tag the policies that will be applied won't always
depend just on the remaining tags..

Your answer is: the operator can change their policies..

We're now going in circles..


> 
>If all the tags for all scopes are declared conflicting then you may be
>breaking more than one policy -- and depending on the expected action the
>disruption may be significant
>
>--------------------------------------------------------------------------
>-----------------------------------------------------------------------
>
>The real problem is not whether the tags are configured to change when
>the topology does, the real problem is for the tags to change a lot and
>become unstable.  The only reason the tags will become unstable due to
>topology changes is if the topology is unstable itself.  However, there
>may be other reasons for tag instability.  For example, what it someone
>decides they want a tag to reflect available bandwidth (or any other
>constantly changing parameter)?
>
>My point here is that it is ok for you to put in the suggestion about
>stability.  It would be even better if you talked about rate limiting the
>origination of the TLVs with updated/changed tags (which is the stability
>you seem to want to enforce); you can even make that normative. However,
>you're trying (again) to limit potential applications that may not result
>in the stability problem that you're trying to prevent..and at the same
>time leaving the door open to other potential stability issues.
>
>In short, if stability is your concern, then address it directly!
>
><Shraddha> The paragraph begins with below statement.
>
>"Being part of the RI LSA, the per-node administrative tag
>TLV must be reasonably small and stable."
>
>I think that should address the stability problems.

It should.  This is the text I quoted originally:

"Being part of the RI LSA, the per-node administrative tag TLV must be
reasonably small and stable...implementations supporting the per-node
administrative tags MUST NOT tie advertised tags to changes in the
network topology (both within and outside the OSPF domain) or
reachability of routes."


Again, the point was that by not allowing the tags to be tied to changes
in topology you are not necessarily doing much to limit instability.
True, the topology may become unstable and the tags advertised will mirror
that -- the root cause being the topology instability.  But I think there
can be valid applications that could follow topology changes that won't
mirror instability (if the network itself is stable).  Also, you focused
on one thing (topology instability), leaving other reasons for tag
instability without mention -- this last part was why I suggested that you
might want to focus on the problem you really want to resolve and maybe
talk about rate limiting.