RE: [Pce] Last Call: <draft-ietf-pce-pcep-service-aware-12.txt> (Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).) to Proposed Standard

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 31 August 2016 13:18 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8F912D4FB; Wed, 31 Aug 2016 06:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 Fb-xAU1oowzL; Wed, 31 Aug 2016 06:18:11 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E6112DB6C; Wed, 31 Aug 2016 06:18:10 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u7VDHxa8031372; Wed, 31 Aug 2016 14:17:59 +0100
Received: from 950129200 ([79.141.128.249]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id u7VDHwoF031363 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2016 14:17:59 +0100
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Dhruv Dhody' <dhruv.dhody@huawei.com>, ietf@ietf.org
References: <147197513470.30697.9830247130594037700.idtracker@ietfa.amsl.com> <044d01d202c8$b28c7570$17a56050$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8C94CE75@blreml501-mbx>
In-Reply-To: <23CE718903A838468A8B325B80962F9B8C94CE75@blreml501-mbx>
Subject: RE: [Pce] Last Call: <draft-ietf-pce-pcep-service-aware-12.txt> (Extensions to the Path Computation Element Communication Protocol (PCEP) to compute service aware Label Switched Path (LSP).) to Proposed Standard
Date: Wed, 31 Aug 2016 14:17:59 +0100
Message-ID: <006201d2038a$19430b00$4bc92100$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIDAhEo3aZ9zpS5K2F2ZISuK5p1SwFHTk3kApRTsJmf4jFBEA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22546.007
X-TM-AS-Result: No--13.639-10.0-31-10
X-imss-scan-details: No--13.639-10.0-31-10
X-TMASE-MatchedRID: u7Yf2n7Ca/1fsB4HYR80ZggKAWhuC2ojCckvlPjoBZHMsBoiFjsqUy7m 8LbVc9tPJx1+EaA81nJ1Luz0vLZcOHYIQoHEix+qvJsORwCzNhFWjiXAsVR2K0UNHQAoZf5cl4j XI5aGT4A9TN0mhYMUXEw1ArvCHgDHk7V5eyy3lZzAzkaoCiomKmYSXiZOvYmP+j47Ih6SwUk/8y JL1KErHUXBRTTN1gI908hHYR1XPJwOSXKAkmvShjHzsy28T+GVFpw9gj8mywq6pZ/o2Hu2YVd+t feWJ6WuPXBcjLOnSLXRR8x1Rs/ILzmkvVO2eNn+ngIgpj8eDcC063Wh9WVqgnXA+T8YcZkDC5Mu mjkcRzWOhzOa6g8KrSBFZ7USbhDA0Fb4tmguzYlXtm18vLu15sY/eJM+TvN2KT5fjtujXRM=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/5PeA1c-TLVhBZyMP-Rvd0Bj3Qpo>
Cc: pce@ietf.org, draft-ietf-pce-pcep-service-aware@ietf.org, pce-chairs@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 31 Aug 2016 13:18:13 -0000

Nice job and very fast!

I am happy with all the changes, but one caution...

> > 4.2.3.1 should not define legacy behavior. A legacy node will not see this
> > spec and cannot be influenced by what you write. So...
> >
> > OLD
> >    If a PCE receives a PCReq message containing a BU object, and the PCE
> >    does not understand or support the BU object, and the P bit is clear
> >    in the BU object header then the PCE SHOULD simply ignore the BU
> >    object.
> >
> >    If the PCE does not understand the BU object, and the P bit is set in
> >    the BU object header, then the PCE MUST send a PCErr message
> >    containing a PCEP-ERROR Object with Error-Type = 3 (Unknown object)
> >    and Error-value = 1 (Unrecognized object class) as per [RFC5440].
> > NEW
> >    The behavior of a PCE that does not understand an object that it
> >    receives on PCReq message is defined in [RFC5440] and depends on the
> >    setting of the P bit in the object header (P bit clear means ignore
> >    the object, P but set means return an "Unknown object" error).
> > END
> >
> [Dhruv] I have updated it as -
>      If the BU object is unknown/unsupported, the PCE MUST follow
>      procedures defined in [RFC5440]. That is, if the P bit is set, the
>      PCE sends a PCErr message with error type 3 or 4 (Unknown / Not
>      supported object) and error value 1 or 2 (unknown / unsupported
>      object class / object type), and the related path computation
>      request MUST be discarded.  If the P bit is cleared, the PCE is
>      free to ignore the object.

You still have normative language in this document to describe how an
implementation that has not read this document is required to behave.  I don't
think that can work.

I suggest s/MUST/will/.

Cheers,
Adrian