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

Great!

We have circulated a new version amongst the authors that addresses  some
(but not all) of these, so thank you very much! We will fix anything still
outstanding and submit early next week. 

Br, Dan. 

-----Original Message-----
From: pce-bounces@ietf.org [mailto:pce-bounces@ietf.org] On Behalf Of Julien
Meuric
Sent: 05 July 2013 16:05
To: pce@ietf.org
Subject: 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

_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce