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" <> Wed, 31 August 2016 13:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8F8F912D4FB; Wed, 31 Aug 2016 06:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.62
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fb-xAU1oowzL; Wed, 31 Aug 2016 06:18:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 29E6112DB6C; Wed, 31 Aug 2016 06:18:10 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id u7VDHxa8031372; Wed, 31 Aug 2016 14:17:59 +0100
Received: from 950129200 ([]) (authenticated bits=0) by (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 <>
To: 'Dhruv Dhody' <>,
References: <> <044d01d202c8$b28c7570$17a56050$> <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$>
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-
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: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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...

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