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

[Oscar González de Dios <[e-mail]>]

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