Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10

"Adrian Farrel" <> Mon, 13 May 2019 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E2E5012008C; Mon, 13 May 2019 13:31:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gpx19MckBEQh; Mon, 13 May 2019 13:31:40 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDBB8120075; Mon, 13 May 2019 13:31:39 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id x4DKVWAq011439; Mon, 13 May 2019 21:31:32 +0100
Received: from (unknown []) by IMSVA (Postfix) with ESMTP id 1C06822044; Mon, 13 May 2019 21:31:32 +0100 (BST)
Received: from (unknown []) by (Postfix) with ESMTPS id 063A422042; Mon, 13 May 2019 21:31:32 +0100 (BST)
Received: from LAPTOPK7AS653V ([]) (authenticated bits=0) by (8.14.4/8.14.4) with ESMTP id x4DKVUuu001244 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 May 2019 21:31:31 +0100
From: Adrian Farrel <>
To:, 'Alissa Cooper' <>, 'Roni Even' <>
References: <> <> <006f01d509bf$f3edf740$dbc9e5c0$>
In-Reply-To: <006f01d509bf$f3edf740$dbc9e5c0$>
Date: Mon, 13 May 2019 21:31:31 +0100
Organization: Old Dog Consulting
Message-ID: <016501d509ca$da082bb0$8e188310$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIWujtCCN4XrPFhwIxqOyq7y/YkkgKBxXpeAiT9l1WlwOd+kA==
Content-Language: en-gb
X-TM-AS-Product-Ver: IMSVA-
X-TM-AS-Result: No--5.888-10.0-31-10
X-imss-scan-details: No--5.888-10.0-31-10
X-TMASE-Result: 10--5.888500-10.000000
X-TMASE-MatchedRID: fE0JoqABJp1OM38HnYL3cf7Ge87NpaCwaMmm586o4gB7ZWRAqE4ZPWr4 /y/RCSUy/zge0+oncdf7Brv946bj5iWM+sp1XKwwvOAv94sAIMQL8TGleseLPBra6jjhXqeTGd1 VXI+QnqwBYQCJTpK4HzAaBOcCLNdVBmjPEm4v5DNNq5/Y+tFvW1WiBZGwRpH+6ZQigqVYehDx83 vPTy5LDcPX1Zxz1PXPYok0dCCCbDHoSi9uJV6wyZCANcFtZ7wT+LidURF+DB08CT+UyeMDYhSId 9SZL66WmeCmAGsWyHLDO+xbEI/WFhnVUjUNUvhlqtgK4BzlMLKD33mO/UVvMwCOLD+ckgKHxlmo in0ixe6mkYieAXD4DWKHpZv+RSYvVHa5Ax0DhIhz5CFYokzTg1+GoijagtkjmyiLZetSf8nJ4y0 wP1A6ADMMszeAZpzJdB0ntd9Tzp6yO81X3yak807y4cOIEcY0mgnTp4e35LI5opIGL7TxT0pFeY 3bN1FVZudgyTpyhTJ+3BndfXUhXQ==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [Gen-art] [Pce] Genart last call review of draft-ietf-pce-hierarchy-extensions-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 May 2019 20:31:42 -0000


Thanks, Dan, for your response here.

Just to follow up on one point:

>> 2. In section 3.2.1 or section 4.1 if the originator sends PCC or PCE
>> sends an open with P flag =0 can the response open be sent with a
>> P flag =1 and if yes what should be the action of the originator. I 
>> did not see any text about this case.
> DK>> According to RFC 5440, the Open message is not a request response
> exchange. Both entities send an Open message, and indeed they may even
> overlap. In our H-PCE extensions the P flag indicates that the sender
> the receiver to act as its parent. In the example we give, it should be
> for one party to not set the P flag in the first Open message seen on the
> wire, and for the second part to set the P flag in the second Open message
> seen on the wire. Therefore, I don't think this needs to be address as an
> implementor should be familiar with the Open message behavior. 

Dan is right that the Open is not a request response exchange, but two Open
messages that flow (one in each direction). The second might be sent in
response to the first, or they might be originated independently and be
matched up.

The P flag applies to the sender's requested relationship with the receiver.
It is possible for:
- neither Open to have the P flag set
- both Opens to have the P flag set
- either one of the Opens to have the P flag set
But, if both Opens have the P flag set then the session set-up must fail
according to 3.1.1.
If one speaker doesn't like the setting of the P flag it receives (most
notably if the receiver does not want to act as a parent) it fails the
session according to 4.1.