Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

"Yemin (Amy)" <amy.yemin@huawei.com> Mon, 08 April 2019 09:49 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E4E1202CA; Mon, 8 Apr 2019 02:49:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kBShKBsj0CAW; Mon, 8 Apr 2019 02:49:56 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792B41201BF; Mon, 8 Apr 2019 02:49:56 -0700 (PDT)
Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DAD56EF99B9C553C2C72; Mon, 8 Apr 2019 10:49:54 +0100 (IST)
Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 8 Apr 2019 10:49:54 +0100
Received: from lhreml706-chm.china.huawei.com (10.201.108.55) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 8 Apr 2019 10:49:54 +0100
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml706-chm.china.huawei.com (10.201.108.55) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 8 Apr 2019 10:49:54 +0100
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.72]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0415.000; Mon, 8 Apr 2019 17:49:31 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" <draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org>
CC: General Area Review Team <gen-art@ietf.org>
Thread-Topic: Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
Thread-Index: AQHU5Yk31HWCp9UXpUyAzdBEenCTZKYqGvlQ
Date: Mon, 08 Apr 2019 09:49:31 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFBD675A@DGGEMM528-MBX.china.huawei.com>
References: <b56bca60-c107-39c2-8cb7-5aede95731e4@alum.mit.edu>
In-Reply-To: <b56bca60-c107-39c2-8cb7-5aede95731e4@alum.mit.edu>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.169.30.234]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/tNWAFgtHhO7Dx_v6S5ou11Wk3Xc>
Subject: Re: [Gen-art] Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Apr 2019 09:49:58 -0000

Hi Paul, 

In 3.10 of RFC2205, e.g., Unknown C-Type for Known Class, 
"Generally, the appearance of an object with unknown C-Type should result in rejection of the entire message and generation of an error message (ResvErr or PathErr as appropriate)."
It use "should" but in lower case. 
 
In additional to RFC2205, RFC5711 defines "Node Behavior upon Originating and Receiving Resource Reservation Protocol (RSVP) Path Error Messages".
In section 2.1 of RFC5711, 
"In the case of fatal errors ("Hard Preemption"; see Section 4.7.3 of [RFC3209] ), the detecting node MUST send a PathErr message reporting the error condition, ....  
In the case of non-fatal errors, the detecting node should send a PathErr message, and must not clear control plane or data plane state. "

Considering the case in this draft, such error can be considered as non-fatal error (the path can still be set up disregarding the Availability TLV), thus SHOULD is more appropriate here.  

BR,
Amy
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] 
Sent: Friday, March 29, 2019 1:10 AM
To: draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org
Cc: General Area Review Team <gen-art@ietf.org>
Subject: Gen-ART Telechat review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-14

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please wait for direction from your document shepherd or AD before posting a new version of the draft. For more information, please see the FAQ at <​http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-ccamp-rsvp-te-bandwidth-availability-14
Reviewer: Paul Kyzivat
Review Date: 2019-01-23
IETF LC End Date: 2019-01-31
IESG Telechat date: 2019-04-09

Summary:

This draft is on the right track but has open issues, described in the review.

Issues:

Major: 0
Minor: 1
Nits:  0

1) MINOR (maybe MAJOR):

Section 3.2 includes the following:

     When a node does not support the Availability TLV, it SHOULD
     generate PathErr message with the error code "Extended Class-Type
     Error" and the error value "Class-Type mismatch" (see [RFC2205]).

This seems to be placing a normative requirement on implementations of RSVP that *don't* support this document. That is clearly impossible.

I am guessing that this is the standard normative behavior for implementations of RSVP that encounter a TLV type they don't understand. 
(I tried to find this in RFC2205 but failed.) If so, then this section should be reworded to indicate that this is the behavior that will occur rather than a new normative requirement.

OTOH, if this is not the standard handling for unknown TLV types then you need to rethink this.