Re: [OSPF] [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt

"Les Ginsberg (ginsberg)" <ginsberg@cisco.com> Thu, 28 April 2016 06:32 UTC

Return-Path: <ginsberg@cisco.com>
X-Original-To: ospf@ietfa.amsl.com
Delivered-To: ospf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7058112D11D; Wed, 27 Apr 2016 23:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.516
X-Spam-Level:
X-Spam-Status: No, score=-15.516 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 lMzrWeTJ7yE3; Wed, 27 Apr 2016 23:32:45 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC2BE12B027; Wed, 27 Apr 2016 23:32:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17040; q=dns/txt; s=iport; t=1461825165; x=1463034765; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kIuPWJ3OJr8UwbBB7YRjDUmR9c3wYsHI3TECJhoNnIo=; b=FdrINMg4l9bAJBVFuMZfkdi8tmmjUGRoZd6C4uPCnImqHcKh3OnnHics rGeAxY14ydf/O2ou+bYyjvwGktSbbmBaHvKzCCASkHV0LKZIrTyeIghnA IddvMASl9phCFYNiekuqaL1yyhnPMFBh+IMSrX4gCQtjMas9vp24yDqtu I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQAvriFX/5RdJa1egmxMU30GtHqEc?= =?us-ascii?q?wENgXYihW0CHIEUOBQBAQEBAQEBZSeEQQEBAQQjCkwQAgEIEQQBASgDAgICMBQ?= =?us-ascii?q?JCAIEAQ0FCIgiDrFokR0BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuEVB+CS?= =?us-ascii?q?oJWBYVojTeEcQGFe4VjgjGPGI8vAR4BAUKDa2yIN38BAQE?=
X-IronPort-AV: E=Sophos; i="5.24,545,1454976000"; d="scan'208,217"; a="98732771"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Apr 2016 06:32:40 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3S6WeWJ008403 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Apr 2016 06:32:40 GMT
Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 28 Apr 2016 01:32:40 -0500
Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Thu, 28 Apr 2016 01:32:39 -0500
From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
To: Manav Bhatia <manav@ionosnetworks.com>, Adrian Farrel <adrian@olddog.co.uk>
Thread-Topic: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
Thread-Index: AQHRoQ9WY8DoqBN170GaQg+1of41EZ+e6t5A
Date: Thu, 28 Apr 2016 06:32:39 +0000
Message-ID: <2ed8fd52aff748878d16a7086035ecf2@XCH-ALN-001.cisco.com>
References: <069b01d1a086$46d4d470$d47e7d50$@olddog.co.uk> <CAGS6MpDwgcLZrLZ-0-Xv9feyLEWA0dGuPbf1jdRzWfu5eGvhYw@mail.gmail.com>
In-Reply-To: <CAGS6MpDwgcLZrLZ-0-Xv9feyLEWA0dGuPbf1jdRzWfu5eGvhYw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.14.223]
Content-Type: multipart/alternative; boundary="_000_2ed8fd52aff748878d16a7086035ecf2XCHALN001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/ospf/IKC59u5mdFda4rm2kNtwkclMkYI>
Cc: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-ospf-sbfd-discriminator.all@ietf.org" <draft-ietf-ospf-sbfd-discriminator.all@ietf.org>, OSPF WG List <ospf@ietf.org>
Subject: Re: [OSPF] [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt
X-BeenThere: ospf@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 28 Apr 2016 06:32:46 -0000

Adrian –

As an interested bystander (given I am co-author on the companion IS-IS S-BFD draft) I share the concerns expressed by Carlos and Manav.

Churning S-BFD discriminator assignments is about as likely as churning IP/IPv6 address assignments on a node – it is simply not something that any deployment would be likely to do.
IGP drafts pay close attention to churn for advertisements of information which is expected to be dynamic - https://datatracker.ietf.org/doc/draft-ietf-isis-te-metric-extensions/ is a good example of this. But there is no reason to expect a similar issue with S-BFD discriminators. Therefore, for the same reasons that base protocol specifications do not discuss the impact of churn in advertising prefix reachability we saw no reason to discuss it in the context of advertising S-BFD discriminators.

It would be helpful if you provided some context as to  why you have raised this point.
Thanx.

   Les

From: rtg-dir [mailto:rtg-dir-bounces@ietf.org] On Behalf Of Manav Bhatia
Sent: Wednesday, April 27, 2016 10:32 PM
To: Adrian Farrel
Cc: <rtg-ads@ietf.org>rg>; rtg-dir@ietf.org; draft-ietf-ospf-sbfd-discriminator.all@ietf.org; OSPF WG List
Subject: Re: [RTG-DIR] Rtg Dir review of draft-ietf-ospf-sbfd-discriminator-04.txt

Hi Adrian,

Thanks for the extensive review. I have a minor comment on a minor issue that you raised.


Minor Issues:

I should like to see some small amount of text on the scaling impact on
OSPF. 1. How much additional information will implementations have to
store per node/link in the network? 2. What is the expected churn in
LSAs introduced by this mechanism (especially when the Reflector is
turned on and off)?

Isnt this implementation specific? This is what will differentiate one vendor implementation from the other.

I am not sure how we can quantify this -- any ideas?

This is akin to saying that IS-IS, in contrast to OSPFv2, is more attuned for partial SPF runs because the node information is cleanly separated from the reachability information. However, this isnt entirely true. While i concede that node information is mixed with prefix information in OSPFv2, there still are ways in which clever implementations could separate the two and do exactly what IS-IS does.

I took this rather circuitous approach to drive home the point that scalability, churn, overheads on the system are in many cases dependent on the protocol implementation and by that token outside the scope of the IETF drafts.


You *do* have...
   A change in information in the S-BFD Discriminator TLV MUST NOT
   trigger any SPF computation at a receiving router.
...which is a help.

I would be alarmed if an implementation in an absence of this pedantic note triggered SPF runs each time an S-BFD disc changed ! I mean if you understand the idea being discussed then you also understand that a change in this TLV has no bearing on the reachability anywhere. And that knowledge should be enough to prevent SPF runs in most cases !

I know that we have added this note but if we need to explicitly spell such things out in all standards then we clearly have bigger problems ! :-)

Cheers, Manav