Re: [Pce] Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04

Hi authors.

Besides Oscar's, please find my complementary comments (which were stuck 
on my paper).

A comment which globally spans the I-D: there are a few RFC 2119 
keywords, but it feels like there are not enough when defining the 
mechanism's behavior; e.g. the definition of the C bit includes a 
"should" while I would have rather expected a "MUST" (or at least a 
"SHOULD"). Note that the "Manageability" section appropriately uses 
these keywords more frequently (different writer?).

----------
Abstract + Introduction
-----
s/GMPLS networks/GMPLS-controlled networks/ [twice]
----------
Section 2
-----
The definitions of "boundary nodes" and "core tree" begin with "<defined 
term> is...", unlike the others one. I suggest to drop those "<defined 
term> is" phrases in the sentences to make them consistent.

s/PCE (Path Computation Element): an entity/PCE: Path Computation 
Element. An entity/
----------
Section 3
-----
s/GMPLS networks/GMPLS-controlled networks/ [one of my favorites! ;-) ]
----------
Section 5
-----
s/Its also important/It is also important/

The way requirements 5 to 8 are written is not consistent with the 
previous ones; adding "should be supported" at the end of each one would 
address my concern.
----------
Section 6
-----
s/called an Objective Function (OF) may be indicated/called an Objective 
Function (OF), may be indicated/
s/(the Core Tree) should be optimal/(the Core Tree), should be optimal/
----------
Section 7
-----
s/Core Tree Based procedure/Core Tree-based procedure/
s/as a tree, which satisfies/as a tree that satisfies/
s/Path-Key Mechanism/path-key mechanism/
s/the same nodes and links/these nodes and links/
s/Path-key Mechanism can/Path-key mechanism can/
s/BRPC based procedure/BRPC-based procedure/
s/BRPC Based Core Tree/BRPC-Based Core Tree/
s/form a set of paths, we call it a/form all possible sets of paths, we 
call them/
s/point to point, BRPC procedure/point to point BRPC procedure/
s/message is as per/message as per/
s/not necessary pruned/not necessarily pruned/
s/intermediate PCEs.<BR>The reason for/intermediate PCEs. The reason for/
s/its parent PCE/its upstream PCE/ [I'm surprised Oscar missed that one 
;-) ]
s/eventually by looking through all the combinations, and taking one 
sub-path from each set to built one P2MP tree it finds/eventually, by 
looking through all the combinations and taking one sub-path from each 
set to build one P2MP tree, it finds/ [commas + "build"]
s/PCE MAY consider/A PCE MAY consider/
s/Sub Tree Computation/Sub-Tree Computation/
s/these mechanism are/these mechanisms are/

In section 7.4.2, I wonder why the IGP and BGP are not mentioned as 
possible ways of building domain trees based on source/leaves addresses 
(when relevant).

When defining the grafting of leaf nodes, a scalability risk is 
identified on the number of inter-domain PCEP adjacencies. Hierarchical 
PCE is mentioned, which is relevant, but I fail to see this as an 
"alternative": both are alike in their hub and spoke approach, and the 
latter does not address the former issue. I would rephrase that as a 
commonalty rather than an "alternative".

Related noted: the previous explanation is given 3 three times within 2 
pages (sections 7.3, 7.5 and 7.6). Given that section 7.5 focuses on it, 
I would put the text there and prune some from other sections.
----------
Section 9
-----
s/configuration MAYBE stored/configuration MAY be stored/
s/and that this information/and this information/
s/The are also/They are also/
----------
References
-----
The number of normative references looks minimized, but I believe that 
at least RFC 5441 is normative in the document.
----------

Enjoy the week-end,

Julien

On 06/18/2013 07:47, Daniel King wrote:
>
> Thanks Oscar! This will really help improve the readability of the 
> draft. We will update the draft, but also respond to each of the 
> points specifically and clarify any technical issues.
>
> Br, Dan.
>
> *From:*Oscar González de Dios [mailto:ogondio@tid.es]
>
> Dear authors of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04,
>
> Please find bellow some comments regarding the PCEP P2MP Procedures 
> draft (sorry for sending them after the 2 weeks deadline for the LC 
> comments):
>
> - There is a strange page jump in the Terminology section. After 
> "RFC5862]" and "ABR: " there is whole blank page…
>
> - Terminology section: Blank line missing between Transit/branch 
> domain and VSPT
>
> - During the document there are 3 different acronyms "P2MP LSP" 
> (section 3 ) "P2MP TE-LSP" (this one only in section 6) and "P2MP TE 
> LSP" (the most common in the document). I suggest aligning the 
> terminology and always use the same term to avoid confusion. . For 
> "historical" reasons, "P2MP TE LSP", used in RFC 4461 seems 
> appropriate. The definition of P2M2 TE LSP used in RFC 4661 may be 
> cited too in the terminology section for completeness.
>
> - In the terminology section the term "Boundary node (BN) is defined. 
> However, later on, the term "border node" is also used, presumably as 
> an synonym. I suggest either choose one term for the whole document or 
> include the term border node too in the terminology.
>
> - Section 3. The sentence "A sub-tree is a part of the P2MP tree 
> describing how the root or an intermediate P2MP LSPs minimizes packet 
> duplication when P2P TE sub-LSPs traverse common links" is hard to 
> understand (maybe there is a typo and it should say "the root of an 
> intermediate P2P LSP").
>
> - The term P2P TE sub-LSP is used in section 3. TE sub-LSP is defined 
> in RFC 4661. Maybe it should be worth adding the sub-LSP terms it to 
> the terminology section.
>
> - In section 4 the term "sequence of domains" is also used to refer to 
> the path domain tree. This introduces confusion, as there is also a 
> "domain sequence" term which applies only to P2P. Please use always 
> "path domain tree"
>
> -Section 4, 2nd paragraph, "domain path tree", use the term "path 
> domain tree" defined in the terminology section.
>
> - Section 4, figure 1 legend is "Domain sequence tree". This term is 
> not defined in the terminology. I would prefer to stick to the term 
> "Path Domain tree". Sorry to be picky about the terminology, but 
> reading the document is hard when the terms are mixed as they are very 
> alike….
>
> - Section 4, assumptions, first bullet. Where it says " each of the 
> P2MP destination" it should day "each of the P2MP destinations".
>
> Section 4, assumption 1, "or PCE sequence (i.e. PCE that serves each 
> domain in the path domain tree)". I don't get this point…. Initially 
> it was stated that the path domain tree is known. In this point, is it 
> suggested an alternative to knowing the path domain tree? That is, 
> instead of assuming that the path domain tree is known, what is known 
> is a set of PCEs? Please clarify
>
> Section 4, assumption 1, How is the set of PCEs and their 
> relationships exchanged? What are the relationships that need to be 
> exchanged?
>
> Section 4, assumptions, I guess, there is an (maybe obvious) 
> assumptions that the association domain - PCE is known in advance.
>
> Sesction 4, assumption 4. "The boundary nodes to use on the LSP are 
> pre-determined". Does this mean then that both the path domain tree 
> AND the boundary nodes are known in advance for each possible P2MP 
> combination?
>
> At this point there is something I miss… Later, in section 7, it is 
> mentioned that a core tree is computed. However, it seems from the 
> assumptions that the core tree is fixed in advance… Maybe I am 
> mis-interpreting the assumptions… Please clarify the assumptions of 
> what is really pre-determined and what is computed.
>
> Section 5. requirement 4. I suggest using better "PCReq and PCEReq 
> messages" using the terminology of RFC 5440.
>
> Section 5. The requirements from 5 to 8 are not written like 
> requirements. I suggest re-writing them with requirements language.
>
> Section 6. Objective function 3. The definition of the core tree in 
> the terminology section considers ONLY entry boundary nodes as leaves. 
> However, it seems here both entry and exit BNs are considered. Please 
> clarify… (maybe it should be mentioned only BNs without distinction 
> among entry or exit).
>
> Section 6. Objective function 3 is about limiting the number of entry 
> points to a domain. Why would there be more that one entry point to a 
> domain? I would expect multiple exit points (that is, several boundary 
> nodes to exit to other domains in the tree). Also, given that, by the 
> assumptions in section 4, the path domain tree AND the boundary nodes 
> are flxed, I do not know if this objective function has any impact at 
> all….
>
> In any case, limiting the number of entry points may an additional 
> constraint to the previous objective functions… It seems more a metric 
> constraint rather than an objective function..
>
> Also, is it considered that several of this objective functions can be 
> applied or combined?
>
> Section 6, objective function 4… I don't get that one… could you 
> clarify it?
>
> Section 7.1 The sentence "An optimal core-tree [based on the OF] will 
> be computed with analyzing the nodes and links within the domains" 
> sounds a bit strange… maybe the "with" is not needed in the sentence? 
> Also.. Previously it was mentioned that the core-tree was formed only 
> considering entry and exit nodes, but now, it seems that the core-tree 
> is obtained taking into account the whole set of nodes and links… 
> Please clarify here (or clarify objective function 2 where it says 
> "formed by considering only the entry and exit nodes"…)
>
> - Section 7.3 When mentioning the request with the C bit set I suggest 
> adding "(defined later in section 7.4.1 of this document)", as it is a 
> new flag…
>
> - Section 7.4.2. I guess "domain-sequence" is really the domain tree… 
> One question… the PCE sequence… is a PCE tree?
>
> And that's all :-) I hope the comments can be useful to improve the 
> readability of the draft.
>
> Best Regards,
>
> Oscar
>
> ------------------------------------------------------------------------
>
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede 
> consultar nuestra política de envío y recepción de correo electrónico 
> en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send 
> and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce