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

Shraddha Hegde <shraddha@juniper.net> Tue, 20 October 2015 03:57 UTC

Return-Path: <shraddha@juniper.net>
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 DC4081A0127; Mon, 19 Oct 2015 20:57:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 scflGB7n8Zgg; Mon, 19 Oct 2015 20:57:02 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0782.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:782]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47E3D1A0130; Mon, 19 Oct 2015 20:57:02 -0700 (PDT)
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) with Microsoft SMTP Server (TLS) id 15.1.300.14; Tue, 20 Oct 2015 03:56:46 +0000
Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) with mapi id 15.01.0300.010; Tue, 20 Oct 2015 03:56:46 +0000
From: Shraddha Hegde <shraddha@juniper.net>
To: "Alvaro Retana (aretana)" <aretana@cisco.com>, 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: AQHRBcJ1zljGkIgsJkOozrcND9iPyZ5r+ypQgABz0wCAATwboIAAWwKAgAQszYCAAJfqgIAA/HFQ
Date: Tue, 20 Oct 2015 03:56:45 +0000
Message-ID: <BY1PR0501MB1381424F36A29C5542F34D9BD5390@BY1PR0501MB1381.namprd05.prod.outlook.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> <D24A524F.DE641%aretana@cisco.com>
In-Reply-To: <D24A524F.DE641%aretana@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=shraddha@juniper.net;
x-originating-ip: [116.197.184.14]
x-microsoft-exchange-diagnostics: 1; BY1PR0501MB1381; 5:xummOi8uuqTrIHOiSTfj/nuqPgSGiU1fw9QBSSV2K/g0OwJ8BnMj9K//B0Vt75XA/uNgsO1fowArbtJ0N6Vr3KdrZkMay1cOhykUPKvWqyPwQwtmyNJ/J2OnfAOPANkgusOuc1U4txp13DFlcfumPw==; 24:/WMjKZW9xv3yFB/9t8IbmKOJfJsMD7u8IaY7bqv1nV0yzLVxHTJNa/2AfTw7IAVif64slc8g0ULex0KoeyzqsFcFUjublEQo2etOaCIJFVk=; 20:fy1h78/tjXm4scN2O4X8E9/KZI1FMxckEx302PJRJPOntmF+7L9T2d5DLgz7KitRNl8nG6YmB4fw2D+XnZ0xuQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR0501MB1381;
x-microsoft-antispam-prvs: <BY1PR0501MB1381171DE7502844D1B04E4AD5390@BY1PR0501MB1381.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(520078)(3002001); SRVR:BY1PR0501MB1381; BCL:0; PCL:0; RULEID:; SRVR:BY1PR0501MB1381;
x-forefront-prvs: 073515755F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(377454003)(13464003)(51444003)(24454002)(479174004)(199003)(74316001)(102836002)(5004730100002)(97736004)(19580405001)(54356999)(33656002)(76176999)(66066001)(64706001)(2900100001)(76576001)(2950100001)(77096005)(11100500001)(101416001)(5001770100001)(5008740100001)(81156007)(19580395003)(86362001)(50986999)(93886004)(5007970100001)(106356001)(92566002)(99286002)(40100003)(122556002)(87936001)(10400500002)(106116001)(105586002)(189998001)(230783001)(5003600100002)(5001960100002)(46102003)(5002640100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY1PR0501MB1381; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2015 03:56:45.9892 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY1PR0501MB1381
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/Fmnti6550THiIvcErpNkvVppaPQ>
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: Tue, 20 Oct 2015 03:57:11 -0000

Alvaro,

I'll try to clarify based on my understanding of your comments.

If the same tag value is flooded with multiple scopes, then it will be declared conflicting (for all scopes).
<Shraddha>Yes.
.
  If there are policies that are dependent on those tags then they won't be applied
<Shraddha> The conflicting tag won't be considered. Lets say a node had advertised 10 tags. Lets say 10th tag is conflicting and is arriving
                       In different scopes. Only 9 tags will be sent to policy. 
                       If you saying just because one tag is conflicting the whole set of tags for that node is ignored, then that's not the case.

 -- 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..

<Shraddha> Again I don't understand your statement. Why can't the policy be applied on only 9 tags in above example. If the policy fails because of the absence of 10th flag then it's an issue with the advertising router being nod-ABR and having advertised different tags in different scopes.

Do you mean to say we should not restrict same tag being advertised in different scopes?
I am not sure If we can change that at this stage of the document since WG as well as others who reviewed the document so far are OK with that restriction being there.

-----------------------------------------------------------------------------------------------------------------------------------------

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.

<Shraddha> Personally, I do not think we need to talk about rate limiting of node-admin tags since we already have rate limiting for the LSA origination.
Would like to hear others opinion on this.

Rgds
Shraddha

-----Original Message-----
From: Alvaro Retana (aretana) [mailto:aretana@cisco.com] 
Sent: Monday, October 19, 2015 6:09 PM
To: Shraddha Hegde <shraddha@juniper.net>et>; The IESG <iesg@ietf.org>
Cc: Acee Lindem (acee) <acee@cisco.com>om>; draft-ietf-ospf-node-admin-tag.ad@ietf.org; draft-ietf-ospf-node-admin-tag.shepherd@ietf.org; draft-ietf-ospf-node-admin-tag@ietf.org; ospf-chairs@ietf.org; ospf@ietf.org
Subject: Re: Alvaro Retana's Discuss on draft-ietf-ospf-node-admin-tag-07: (with DISCUSS and COMMENT)

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.