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

Dhruv Dhody <dhruv.dhody@huawei.com> Wed, 31 August 2016 18:10 UTC

Return-Path: <dhruv.dhody@huawei.com>
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 1E79712D5FB; Wed, 31 Aug 2016 11:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.769
X-Spam-Level:
X-Spam-Status: No, score=-4.769 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.548, 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 PggbFtUmx9zm; Wed, 31 Aug 2016 11:10:35 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0564212D60E; Wed, 31 Aug 2016 11:10:34 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQN31654; Wed, 31 Aug 2016 18:10:32 +0000 (GMT)
Received: from BLREML408-HUB.china.huawei.com (10.20.4.47) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 31 Aug 2016 19:10:29 +0100
Received: from BLREML501-MBX.china.huawei.com ([10.20.5.198]) by BLREML408-HUB.china.huawei.com ([10.20.4.47]) with mapi id 14.03.0235.001; Wed, 31 Aug 2016 23:40:18 +0530
From: Dhruv Dhody <dhruv.dhody@huawei.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, "ietf@ietf.org" <ietf@ietf.org>
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
Thread-Topic: [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
Thread-Index: AQHR/Wg752AP6CDTy0GRHufVhtugzKBhOl4AgAFJqxCAADkjgIAArZGw
Date: Wed, 31 Aug 2016 18:10:17 +0000
Message-ID: <23CE718903A838468A8B325B80962F9B8C94D4D6@blreml501-mbx>
References: <147197513470.30697.9830247130594037700.idtracker@ietfa.amsl.com> <044d01d202c8$b28c7570$17a56050$@olddog.co.uk> <23CE718903A838468A8B325B80962F9B8C94CE75@blreml501-mbx> <006201d2038a$19430b00$4bc92100$@olddog.co.uk>
In-Reply-To: <006201d2038a$19430b00$4bc92100$@olddog.co.uk>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.18.79.246]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.57C71D99.00D5, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: fa3eb1cb63a79498e31d96c2a556eb89
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/ffJWXg4SH7cBxdw4bAlWXhe5CBM>
Cc: "pce@ietf.org" <pce@ietf.org>, "draft-ietf-pce-pcep-service-aware@ietf.org" <draft-ietf-pce-pcep-service-aware@ietf.org>, "pce-chairs@ietf.org" <pce-chairs@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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 18:10:38 -0000

Hi Adrian, 

Ack.
Updated in working copy. 

Regards,
Dhruv

> -----Original Message-----
> From: Adrian Farrel [mailto:adrian@olddog.co.uk]
> Sent: 31 August 2016 18:48
> To: Dhruv Dhody <dhruv.dhody@huawei.com>; ietf@ietf.org
> Cc: pce@ietf.org; draft-ietf-pce-pcep-service-aware@ietf.org;
> pce-chairs@ietf.org; 'Dhruv Dhody' <dhruv.ietf@gmail.com>
> 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
> 
> 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