Thanks Julien, good comments. We will take these and Filippo's and update accordingly.
Br, Dan. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 09 September 2009 18:43 To: [email protected]; [email protected] Cc: [email protected] Subject: Re: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt Hi Itaru, hi Dan. Here are some comments on draft-ietf-pce-pcep-svec-list-02, mostly editorial (some of them were already pointed out by Filippo). As a non native English speaker, some of them may be irrelevant but one of the authors being native, I am sure we will find kingly solutions. -------------------- As recommended (http://www.ietf.org/mail-archive/web/pce/current/msg02045.html), move the abstract on the 1st page, before the "Status of this Memo". -------------------- (Current) Page 2 ---------- OLD: protected path do not share common network points NEW: protected path which do not share common network points (alt NEW: protected path not sharing common network points) ---------- OLD: the working and protected path disjoint objective NEW: the working and protected path diversity/disjunction/disjointness objective -> The term can be discussed, but I feel more comfortable with a noun rather than an adjective. -------------------- Page 3 ---------- OLD: PCEP facilitates NEW: PCEP specifies/defines/standardizes... (Facilitates the interworking, not the communication.) ---------- OLD: reoptimize a set of service NEW: reoptimize a set of services -------------------- Page 4 ---------- OLD: o Single domain, multiple-PCE NEW: o Single domain, multi-PCE + alignment to the left to be adjusted -------------------- Page 5 ---------- OLD: The association among multiple SVECs for multiple sets of synchronized dependent path computation and disjoint VSPT encoding rule for end-to-end diverse path computation across domains are also described in this document. NEW: The association among multiple SVECs for multiple sets of synchronized dependent path computation is also described in this document as well as the disjoint VSPT encoding rule for end-to-end diverse path computation across domains. + Appart from the terminology section, this is the 1st occurrence of VSTP. As other acronyms are expanded the 1st time you use them, VSTP should also be expanded here. ---------- OLD: scenarios are out of scope in this document NEW: scenarios are out of the scope of this document ---------- OLD: The SVEC association and disjoint VSPT are available to both multiple PCE path computations as well as a single PCE path computation. NEW: The SVEC association and disjoint VSPT are available to both multi-PCE path computation and single PCE path computation. (alt NEW: The SVEC association and disjoint VSPT are available to multi-PCE path computation as well as single PCE path computation.) ---------- OLD: When computing two or more point-to-point diverse paths, a PCE may compute these diverse paths concurrently NEW: A PCE may compute two or more point-to-point diverse paths concurrently ---------- OLD: primary and secondary path disjoint objective NEW: primary and secondary path diversity/disjunction/disjointness objective (as above) -------------------- Page 6 ---------- For point-to-multipoint path requests,SVEC association can be applied. -> missing space before "SVEC". ---------- OLD: point-to-multipoint paths and its secondary paths NEW: Point-to-multipoint paths and their secondary paths (capital letter + "their") -------------------- Page 7 ---------- OLD: Associated SVECs mean that NEW: Associated SVECs means that (alt NEW: "Associated SVECs" means that) ---------- OLD: only one request-ID may in the SVEC object NEW: only one request-ID in the SVEC object ---------- OLD: all of the path computation requests NEW: all the path computation requests ---------- OLD: the first SVEC is associating the other SVECs NEW: the first SVEC is associated with the other SVECs -------------------- Page 8 ---------- OLD: When PCEP receives NEW: When a PCE receives ---------- OLD: requests between multiple PCE`s NEW: requests between multiple PCEs -------------------- Page 9 ---------- OLD: Furthermore, if the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain. NEW: Furthermore, if the PCReq message contains multiple associated SVEC objects and these SVEC objects contain path computation requests that will be sent to the next PCE along the path computation chain, the following procedure applies. ---------- OLD: received from neighbor PCEs NEW: received from all neighbor PCEs ---------- OLD: network operator`s point of view NEW: network operator's point of view ---------- The 2-step approach is described in [RFC5521]. -> No strong opinion here, but I find it easier to read for human beings when recalling what stands behind a RFC number (just as you do for RFC 5520 on page 11). For instance, you could append "and uses eXclude Route Object (XRO)" to the sentence. ---------- OLD: VSPT (virtual shortest path tree) NEW: VSPT -> Expansion should be sent to the introduction (see above). -> I like it with capital letters where appropriate. ---------- OLD: disjoint information among the potential paths NEW: diversity/disjunction/disjointness information among the potential paths ---------- OLD: to preserve disjoint information NEW: to preserve diversity/disjunction/disjointness information -------------------- Page 10 ---------- OLD: boarder nodes NEW: border nodes ---------- OLD: BR5 NEW: BN5 (on Figure-1) ---------- OLD: Figure-1; NEW: Figure-1: ---------- OLD: VSPTx; NEW: VSPTx: (3 times on Figure-2) ---------- OLD: BRx NEW: BNx (6 times on Figure-2) ---------- OLD: Figure-2; NEW: Figure-2: -------------------- Page 11 ---------- RP object; EROs -> Mentioned for the 1st time in the document, expansions would be welcome. ---------- OLD: Detail disjoint VSPT encoding NEW: Detailled disjoint VSPT encoding ---------- The 2 lines starting with "ERO1" and "ERO2" need to be brought into alignment. ---------- OLD: BRx NEW: BNx (6 times) ---------- OLD: ERO6... [for VSPT2] NEW: ERO6... [for VSPT3] ---------- OLD: PCE sending PCreq NEW: PCE sending PCReq -------------------- Page 12 ---------- OLD: If PCreq has NEW: If PCReq has ---------- OLD: the received PCrep NEW: the received PCRep ---------- OLD: the received VSTP NEW: the received VSPT ---------- o the capability to configure SVEC association. -> Should be deleted. -------------------- Page 13 ---------- OLD: the security of this document depends on that of PCEP protocol NEW: the security of the procedures described in this document depends on PCEP protocol -> We could discuss "the security of this document", but it will require a few beers... And yes, some people actually read the security section! ;-) -------------------- Page 15 ---------- Dan's address is just "UK", which I am perfectly fine with since noone ever needs to contact Old Dog Consulting, especially in the Routing Area. ---------- Good luck for the update, Julien -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of JP Vasseur Dear all, This starts a 2-week WG Last Call for draft-ietf-pce-pcep-svec- list-02.txt, which has been stable for quite some time, and is ready for WG Last call. Please send your comments by September 16, 9:00am ET on the mailing list. We would also welcome feed-back from potential implementers. Thanks. JP and Julien. _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce _______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
