[RTG-DIR] Routing directorate review of draft-ietf-ccamp-ospf-availability-extension

Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com> Tue, 26 July 2016 16:47 UTC

From: Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
To: "<rtg-ads@ietf.org> (rtg-ads@ietf.org)" <rtg-ads@ietf.org>, "BRUNGARD, DEBORAH A" <db3546@att.com>, "draft-ietf-ccamp-ospf-availability-extension@ietf.org" <draft-ietf-ccamp-ospf-availability-extension@ietf.org>
Thread-Topic: Routing directorate review of draft-ietf-ccamp-ospf-availability-extension
Thread-Index: AdHnVnOUGjdb5imQQwaNvYczptDqdw==
Date: Tue, 26 Jul 2016 16:47:27 +0000
Message-ID: <BY2PR0201MB191071DB974F8C4ED02D1A89840E0@BY2PR0201MB1910.namprd02.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
received-spf: None (protection.outlook.com: metaswitch.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR0201MB191071DB974F8C4ED02D1A89840E0BY2PR0201MB1910_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2016 16:47:27.6495 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 9d9e56eb-f613-4ddb-b27b-bfcdf14b2cdb
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0201MB1909
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/uX2v7qiVkLnTKdKqjaWc5SW4eZs>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: [RTG-DIR] Routing directorate review of draft-ietf-ccamp-ospf-availability-extension
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 16:47:45 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-ccamp-ospf-availability-extension
Reviewer: Jon Hardwick
Review Date: 26 July 2016
IETF LC End Date: Not started yet
Intended Status: Proposed standard

== Summary ==
I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

== Comments ==
This document addresses the situation where the maximum bandwidth of some links in the network can vary over time, for example due to radio interference. Specifically, it addresses the path computation problem, where service placement must take these fluctuations into account.

OSPF is extended to flood the “availability” of such links, which is defined as a sequence of <bandwidth, percentage> tuples. Each tuple tells the percentage of time at which the bandwidth of the link will be at least as much as <bandwidth>, for example <100Mbps, 99.99%>. This information is added to the ISCD TLV, defined in RFC 4203. When services are being planned, the planner specifies the service’s availability requirement (e.g. 4-nines) and the path is computed accordingly.

The document is written in good English and easy enough to understand, and is commendably brief, although probably too brief – see below.

== Major Issues ==

1) The specification of the protocol extensions appears incomplete. Specifically, section 1 says:

The extension
reuses the reserved field in the ISCD and also introduces an
optional Availability sub-TLV.

However, no further mention is made of the ISCD’s reserved field. How is it reused?

The following description of the Availability level is difficult to understand and leaves me with several questions:

This field is a 32-bit IEEE floating point number which

describes the decimal value of availability guarantee of the

switching capacity in the ISCD object which has the AI value

equal to Index of this sub-TLV.

- What is the “switching capacity” of the ISCD object? Do you mean “switching capability” like PSC-1 etc.?
- What is the AI value? This term is not defined.
- What do you mean by the index of this sub-TLV? Do you mean the position of this sub-TLV in the list of ISCD sub-TLVs? What if somebody defines a new ISCD sub-TLV in future – won’t that mess up the indexing?

2) The proposed extensions are not backwards compatible, so do not support incremental deployment. In section 3.2 it says:

A node that doesn't support ISCD Availability sub-TLV SHOULD ignore

ISCD Availability sub-TLV.

However, it’s not possible for this document to specify the behaviour of nodes that do not support this document. The issue is that the ISCD Availability TLV is defined as a sub-TLV of the ISCD TLV, but the ISCD TLV defined in RFC 4203 has no sub-TLVs. Therefore, implementations of RFC 4203 that do not support this draft will reject the ISCD TLVs sent by implementations of this draft, because they will appear to have the wrong length.

== Minor Issues ==

There are a few cases I would like to see spelled out more clearly in the document.
- How should a node interpret the absence of any ISCD Availability TLVs?
- How should a node interpret more than one ISCD Availability TLV for the same availability level? Is that even legal to send?
- Let’s say a node advertises a link with 10Gbps capacity, and includes an ISCD Availability TLV saying that the link has a 99% availability level at 8Gbps . What (if anything) are we to conclude about its availability at 10Gbps? At 5Gbps?

Section 5 (IANA Considerations). What allocation policy should IANA use for the new sub-registry? See RFC 5226.

Best regards
Jon

Re: [RTG-DIR] [CCAMP] Routing directorate review … Lou Berger
Re: [RTG-DIR] [CCAMP] Routing directorate review … Yemin (Amy)
Re: [RTG-DIR] [CCAMP] Routing directorate review … Lou Berger
Re: [RTG-DIR] [CCAMP] Routing directorate review … Huub van Helvoort
Re: [RTG-DIR] [CCAMP] Routing directorate review … Yemin (Amy)
Re: [RTG-DIR] [CCAMP] Routing directorate review … Lou Berger
Re: [RTG-DIR] Routing directorate review of draft… Daniele Ceccarelli
Re: [RTG-DIR] Routing directorate review of draft… Jonathan Hardwick
Re: [RTG-DIR] Routing directorate review of draft… Yemin (Amy)
Re: [RTG-DIR] Routing directorate review of draft… Jonathan Hardwick
Re: [RTG-DIR] Routing directorate review of draft… Daniele Ceccarelli
Re: [RTG-DIR] Routing directorate review of draft… Yemin (Amy)
[RTG-DIR] Routing directorate review of draft-iet… Jonathan Hardwick