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

From: Alissa Cooper <[email-masked]>
Date: Mon, 13 May 2019 13:23:05 -0400

Roni, thanks for your review. I raised your point about the missing OPEN (error) case in my DISCUSS ballot. One comment below.

> On Apr 14, 2019, at 6:42 AM, Roni Even via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Roni Even
> Review result: Almost Ready
> 
> 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 treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-pce-hierarchy-extensions-??
> Reviewer: Roni Even
> Review Date: 2019-04-14
> IETF LC End Date: 2019-04-15
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> The document is almost ready for publication as a standard track RFC.
> 
> Major issues:
> 
> Minor issues:
> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on the
> internet?

This text is the same as what appears in RFC 7399 and I think it captures the intent clearly enough (although happy to see the authors answer your question).

Thanks,
Alissa

> 
> 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.
> 
> Nits/editorial comments:
> 1. in section 1 "achild" should be " a child"
> 2.  Section 2.4 repeat some of the text from RFC6805 1.3.2.2 but using
> different sentence structure. Is there a reason to change the wording.
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Mon, 13 May 2019 20:13:30 +0100

Hi Roni and Alissa, 

Thanks both for the review. We have addressed the comments from you both in
the latest version (11) but have not posted as it was so close to the IESG
telechat. A few comments  (DK>>) below on the specific comments:

> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the

DK>> The draft (section 1.1) now includes the following text. 

      The hierarchical relationship model is described in [RFC6805].
      It is applicable to environments with small groups of domains 
      where visibility from the ingress LSRs is limited.  As highlighted
      in [RFC7399] applying the hierarchical PCE model to very large 
      groups of domains, such as the Internet, is not considered 
      feasible or desirable.
<<

> what should be the action of the originator. I did not see any text about
this

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 wants
the receiver to act as its parent. In the example we give, it should be fine
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. 

> 1. in section 1 "achild" should be " a child"

DK>> Fixed, thanks!

> different sentence structure. Is there a reason to change the wording.

DK>> In the new version of our I-D (v11) we have three paragraphs for this
section, the first includes text from RFC6805 and uses quotes the reference
text, but we also include some additional discussion (in two further
paragraphs) text not used in 6805 to further define domain diversity. 

DK>> Again, thank you for the reviews. Its very much appreciated. We have a
new version ready which also addresses the above, and comments from Kyle
(secdir) and Mike (rtgdir). 

BR, Dan and the other authors. 

-----Original Message-----
From: Pce <[email-masked]> On Behalf Of Alissa Cooper
Sent: 13 May 2019 18:23
To: Roni Even <[email-masked]>
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Pce] [Gen-art] Genart last call review of
draft-ietf-pce-hierarchy-extensions-10

Roni, thanks for your review. I raised your point about the missing OPEN
(error) case in my DISCUSS ballot. One comment below.

> 1. In section 1.1 last bullet does it mean that you MUST NOT use H-PCEP on
the

This text is the same as what appears in RFC 7399 and I think it captures
the intent clearly enough (although happy to see the authors answer your
question).

Thanks,
Alissa

_______________________________________________
Pce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pce

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 13 May 2019 21:31:31 +0100

Hi,

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

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.

Thanks,
Adrian