Subject: [Gen-art] Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Jun 2014 08:01:10 +0000

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document:                         draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

Reviewer:                           Christer Holmberg

Review Date:                     6 June 2014

IETF LC End Date:             26 May 2014

IETF Telechat Date:        12 June 2014

Summary:                         The document is well written, with some editorial nits that the authors may want to address before publication.

Major Issues: None

Minor Issues: None

Editorial nits:

Q1-G:                                    In the Introduction section, you expand PCE ("Path Computation Element (PCE)"). After that, I suggest you don't expand it anymore. I think you do it in a couple of places, in section 1.2 and 3.

Q2-G:                                    Same as Q_G_1, but for PCEP, which I believe you in addition to the Introduction also expand in section 3.

Q3_1:                                    In section 1, the draft says:

"The ability to compute constrained Traffic Engineering Label Switched Paths (TE
                LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol Label
                Switching (MPLS) and Generalized MPLS (GMPLS) networks across
                multiple domains are therefore required."

                                                Are all these so called well-known terms (I guess at least MPLS is), or would it be useful to add some references when/if appropriate?

Q4_1_2:                               In section 1.2, the draft says:

                "The experiment is intended to enable research for the Path Computation Element (PCE)"

                                                Do you mean to say "to enable research of the usage of the PCE"?

Q5_1_2:                               In section 1.2, the draft says:

                "This document is not intended to replace the intra-domain P2MP path
                computation approach supported by [RFC6006],"

                                                It is a little unclear to me what you mean be "supported by". Does RFC 6006 defined the approach, or does RFC 6006 use an approach defined somewhere else, or?

Q6-7_4_2:                           In section 7.4.2, s/The procedure as described in this document/The procedure described in this document           (remove "as")

Q7_7:                                    In section 7, s/ has following impact -/ has following impacts:

Q8_7:                                    In section 7, instead of saying "requirements specified in the previous section", please point to the actual section, e.g. "requirements specified in section X of this document".

Q9_7:                                    In section 7, the text says:

                "The following sections describe the core-tree based procedures to
                satisfy the requirements specified in the previous section."

                                                Would it be good to also mention the PCEP extensions? E.g.:

                "The following sections describe the core-tree based procedures, including
PCEP extensions, to satisfy the requirements specified in the previous section."

Q10_7:                                  As section 7 (including the sub sections) is quite large, I would suggest to have a section called "7.1 General":

                "7.  P2MP Path Computation Procedures

                7.1. General

A P2MP Path computation can be broken down into two steps of core-
                tree computation and grafting of sub-trees. Breaking the procedure
                ..."

Q11_7_2:                             In section 7.2, s/ messages format as per [RFC5440]/ messages format defined in [RFC5440]

Q12_7_4_2:                        In section 7.4.2, s/ The procedure as described in this document/ The procedure described in this document           (remove "as")

Regards,

Christer

---

From: "Daniel King" <[email-masked]>
Date: Fri, 6 Jun 2014 21:04:03 +0100

Dear Christer, 

Thank you for your Gen-ART review, please see my responses inline ("DK>>"): 

Br, Dan. 

From: Christer Holmberg [mailto:[email-masked]] 
Sent: 06 June 2014 09:01
To: [email-masked]
Cc: [email-masked]
Subject: Gen-ART review of
draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

Document:
draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

Review Date:                     6 June 2014

Summary:                         The document is well written, with some
editorial nits that the authors may want to address before publication.

Major Issues: None

Minor Issues: None

Editorial nits: 

Q1-G:                                    In the Introduction section, you
expand PCE ("Path Computation Element (PCE)"). After that, I suggest you
don't expand it anymore. I think you do it in a couple of places, in section
1.2 and 3.

DK>> Agree. Well spotted, indeed:

1.2 Scope

3.  Examination of Existing Mechanisms

DK>> These can be truncated to "PCE". 

Q2-G:                                    Same as Q_G_1, but for PCEP, which
I believe you in addition to the Introduction also expand in section 3.

DK>> Agree.

3.  Examination of Existing Mechanisms 

DK>> Again, this can be truncated to "PCEP".

"The ability to compute constrained Traffic Engineering Label Switched Paths
(TE

                LSPs) for point-to-multipoint (P2MP) LSPs in Multiprotocol
Label

                Switching (MPLS) and Generalized MPLS (GMPLS) networks
across

                                                Are all these so called
well-known terms (I guess at least MPLS is), or would it be useful to add
some references when/if appropriate?

DK>> These are well-known terms, but we do also state we reuse terminology
which is better defined in specific RFCs in our terminology section. In
summary, I think its ok to leave "as is".

                "The experiment is intended to enable research for the Path
Computation Element (PCE)"

                                                Do you mean to say "to
enable research of the usage of the PCE"?

DK>> Agree. The word "usage" would be more apt. 

                "This document is not intended to replace the intra-domain
P2MP path

                                                It is a little unclear to me
what you mean be "supported by". Does RFC 6006 defined the approach, or does
RFC 6006 use an approach defined somewhere else, or?

DK>> Aha, I see the ambiguity. RFC6006 defines how PCEP is used to compute
P2MP paths in single domain (intra-domain) networks. So perhaps a better
word would be "defined" rather than "supported". 

Q6-7_4_2:                           In section 7.4.2, s/The procedure as
described in this document/The procedure described in this document
(remove "as")

DK>> Agree. 

Q7_7:                                    In section 7, s/ has following
impact -/ has following impacts:

DK>> Agree. In fact, I might suggest "has the following impact:"

Q8_7:                                    In section 7, instead of saying
"requirements specified in the previous section", please point to the actual
section, e.g. "requirements specified in section X of this document".

DK>> Agree.  "requirements specified in section 6. of this document."

                "The following sections describe the core-tree based
procedures to

                                                Would it be good to also
mention the PCEP extensions? E.g.:

                "The following sections describe the core-tree based
procedures, including

PCEP extensions, to satisfy the requirements specified in the previous
section."

DK>> Agree.

Q10_7:                                  As section 7 (including the sub
sections) is quite large, I would suggest to have a section called "7.1
General":

                7.1. General

                tree computation and grafting of sub-trees. Breaking the
procedure

                ."

DK>> Ok, if you think it helps the reader. 

Q11_7_2:                             In section 7.2, s/ messages format as
per [RFC5440]/ messages format defined in [RFC5440]

DK>> Agree.

Q12_7_4_2:                        In section 7.4.2, s/ The procedure as
described in this document/ The procedure described in this document
(remove "as")

DK>> Agree.

Regards,

Christer

DK>> Again, thank you for your review and comments. 

Br, Dan.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 10 Jun 2014 10:43:29 +0300

Christer, Daniel,

Thank you for the review and the responses. I have balloted “No-Objection” and expect that the edits will find themselves to a new draft version some day :-)

Jari

On 06 Jun 2014, at 23:04, Daniel King <[email-masked]> wrote:

> Dear Christer,
>  
> Thank you for your Gen-ART review, please see my responses inline (“DK>>”):
>  
> Br, Dan.
>  
> Subject: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07
>  
> Q1-G:                                    In the Introduction section, you expand PCE (“Path Computation Element (PCE)”). After that, I suggest you don’t expand it anymore. I think you do it in a couple of places, in section 1.2 and 3.
>  
> DK>> These can be truncated to “PCE”.
>  
> DK>> Again, this can be truncated to “PCEP”.
>  
> “The ability to compute constrained Traffic Engineering Label Switched Paths (TE
>                 multiple domains are therefore required.”
>  
> DK>> These are well-known terms, but we do also state we reuse terminology which is better defined in specific RFCs in our terminology section. In summary, I think its ok to leave “as is”.
>  
>                 “The experiment is intended to enable research for the Path Computation Element (PCE)”
>  
>                                                 Do you mean to say “to enable research of the usage of the PCE”?
>  
> DK>> Agree. The word “usage” would be more apt.
>  
>                 “This document is not intended to replace the intra-domain P2MP path
>                 computation approach supported by [RFC6006],”
>  
>                                                 It is a little unclear to me what you mean be “supported by”. Does RFC 6006 defined the approach, or does RFC 6006 use an approach defined somewhere else, or?
>  
> DK>> Aha, I see the ambiguity. RFC6006 defines how PCEP is used to compute P2MP paths in single domain (intra-domain) networks. So perhaps a better word would be “defined” rather than “supported”.
>  
> Q6-7_4_2:                           In section 7.4.2, s/The procedure as described in this document/The procedure described in this document           (remove “as”)
>  
> DK>> Agree.
>  
> DK>> Agree. In fact, I might suggest “has the following impact:”
>  
> Q8_7:                                    In section 7, instead of saying “requirements specified in the previous section”, please point to the actual section, e.g. “requirements specified in section X of this document”.
>  
> DK>> Agree.  “requirements specified in section 6. of this document.”
>  
>                 “The following sections describe the core-tree based procedures to
>                 satisfy the requirements specified in the previous section.”
>  
>                 “The following sections describe the core-tree based procedures, including
> PCEP extensions, to satisfy the requirements specified in the previous section.”
>  
>  
> DK>> Agree.
>  
> Q10_7:                                  As section 7 (including the sub sections) is quite large, I would suggest to have a section called “7.1 General”:
>  
>                 “7.  P2MP Path Computation Procedures
>  
>                 7.1. General
>  
>                 …”
> Q12_7_4_2:                        In section 7.4.2, s/ The procedure as described in this document/ The procedure described in this document           (remove “as”)
>  
> DK>> Agree.
>  
> Regards,
>  
> Christer
>  
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Jun 2014 09:03:13 +0000

Hi Dan,

I am happy with your reply and way forward :)

Regards,

Christer

From: Daniel King [mailto:[email-masked]] On Behalf Of Daniel King
Sent: 6. kesäkuuta 2014 23:04
To: Christer Holmberg; [email-masked]
Cc: [email-masked]
Subject: RE: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

Dear Christer,

Br, Dan.

From: Christer Holmberg [mailto:[email-masked]]
Sent: 06 June 2014 09:01
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

Review Date:                     6 June 2014

Major Issues: None

Minor Issues: None

Editorial nits:

1.2 Scope

DK>> Agree.

DK>> These are well-known terms, but we do also state we reuse terminology which is better defined in specific RFCs in our terminology section. In summary, I think its ok to leave "as is".

DK>> Aha, I see the ambiguity. RFC6006 defines how PCEP is used to compute P2MP paths in single domain (intra-domain) networks. So perhaps a better word would be "defined" rather than "supported".

DK>> Agree.

DK>> Agree.

                7.1. General

DK>> Agree.

DK>> Agree.

Regards,

Christer

Br, Dan.

---

From: "Daniel King" <[email-masked]>
Date: Tue, 17 Jun 2014 17:23:50 +0100

Hi Christer, 

We recently posted the new version with the agreed text updates to address
the items you highlighted. Please let us know if the new versions addresses
your comments. 

http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domain-p2mp-procedures-
08

Thanks for all your help and review effort.

Br, Dan. 

From: Christer Holmberg [mailto:[email-masked]] 
Sent: 10 June 2014 10:03
To: Daniel King; [email-masked]
Cc: [email-masked]
Subject: RE: Gen-ART review of
draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

Hi Dan,

Regards,

Christer

From: Daniel King [mailto:[email-masked]] On Behalf Of Daniel King
Sent: 6. kesäkuuta 2014 23:04
To: Christer Holmberg; [email-masked] <mailto:[email-masked]> 
Cc: [email-masked]
<mailto:[email-masked]>

Subject: RE: Gen-ART review of
draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

Dear Christer, 

Br, Dan. 

From: Christer Holmberg [mailto:[email-masked]] 
Sent: 06 June 2014 09:01
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked]
<mailto:[email-masked]>

Document:

Review Date:                     6 June 2014

Major Issues: None

Minor Issues: None

Editorial nits: 

Q1-G:                                    In the Introduction section, you
expand PCE (“Path Computation Element (PCE)”). After that, I suggest you
don’t expand it anymore. I think you do it in a couple of places, in section
1.2 and 3.

1.2 Scope

DK>> Agree.

“The ability to compute constrained Traffic Engineering Label Switched Paths
(TE

                                                Are all these so called

DK>> These are well-known terms, but we do also state we reuse terminology
which is better defined in specific RFCs in our terminology section. In
summary, I think its ok to leave “as is”.

                “The experiment is intended to enable research for the Path
Computation Element (PCE)”

                                                Do you mean to say “to
enable research of the usage of the PCE”?

                “This document is not intended to replace the intra-domain
P2MP path

                                                It is a little unclear to me
what you mean be “supported by”. Does RFC 6006 defined the approach, or does
RFC 6006 use an approach defined somewhere else, or?

DK>> Aha, I see the ambiguity. RFC6006 defines how PCEP is used to compute
P2MP paths in single domain (intra-domain) networks. So perhaps a better
word would be “defined” rather than “supported”. 

(remove “as”)

DK>> Agree. 

Q8_7:                                    In section 7, instead of saying
“requirements specified in the previous section”, please point to the actual
section, e.g. “requirements specified in section X of this document”.

                “The following sections describe the core-tree based
procedures to

                                                Would it be good to also

                “The following sections describe the core-tree based
procedures, including

section.”

DK>> Agree.

Q10_7:                                  As section 7 (including the sub
sections) is quite large, I would suggest to have a section called “7.1
General”:

                7.1. General

                …”

 

DK>> Agree.

(remove “as”)

DK>> Agree.

Regards,

Christer

Br, Dan.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Jun 2014 13:40:30 +0000

Hi,

It otherwise looks good, but I think you should keep "Path Computation Element (PCE) [RFC4655]" in section 1, because it's the first occurance (not counting the Abstract).

Regards,

Christer

From: Daniel King [[email-masked]] on behalf of Daniel King [[email-masked]]
Sent: Tuesday, 17 June 2014 7:23 PM
To: Christer Holmberg; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Gen-ART review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-07

Hi Christer, 

We recently posted the new version with the agreed text updates to address the items you highlighted. Please let us know if the new versions addresses your comments. 

http://tools.ietf.org/html/draft-ietf-pce-pcep-inter-domain-p2mp-procedures-08

Br, Dan. 

Hi Dan,

Regards,

Christer

Dear Christer, 

Br, Dan. 

Review Date:                     6 June 2014

Major Issues: None

Minor Issues: None

Editorial nits: 

1.2 Scope

DK>> Agree.

DK>> Agree. 

DK>> Agree.

                7.1. General

DK>> Agree.

DK>> Agree.

Regards,

Christer

Br, Dan.