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

["Daniel King" <[e-mail]>]

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:[e-mail]] 
Sent: 17 June 2013 17:09
To: [e-mail];
[e-mail]
Subject: Review of draft-ietf-pce-pcep-inter-domain-p2mp-procedures-04

 

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