Subject: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt

From: JP Vasseur <[email-masked]>
Date: Tue, 1 Sep 2009 20:30:25 +0200

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.

---

From: "Filippo Cugini" <[email-masked]>
Date: Wed, 2 Sep 2009 18:47:21 +0200

Hi,

just one clarification in the case of multiple associated end-to-end diverse
path computations.
Example: consider one additional end-to-end diverse path computation (say
Requests #3 and #4, source S2 and dest. D2) associated to the diverse
path computation S1-D1 reported in section 6.
The EROs computed for Req #1 and #2 (those in section 6.2) may be related to
the EROs computed for Req #3 and #4.
Thus, up to 9 EROs per request could be necessary in each path list.
However, if the two sets of computed EROs are independent, up to 3 EROs per
request would be sufficient (as in 6.2).
Is it required to enclose in the PCRep message all the combinations (even if
they are independent)?

Few typos:
- section 4.1, "may in the SVEC may"
- 6.2, last line, VSPT2 -> VSPT3
- 6.3, VSTP -> VSPT

Br,
  Filippo

----- Original Message ----- 
From: "JP Vasseur" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, September 01, 2009 8:30 PM
Subject: [Pce] Working Group Last Call: draft-ietf-pce-pcep-svec-list-02.txt

> 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.
>
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce

---

From: "Itaru Nishioka" <[email-masked]>
Date: Tue, 8 Sep 2009 22:14:29 +0900

Hi Filippo

Thank you for comments.

For independent request, it is not required to reply all combinations (just 3 EROs replied in
section 6.2), because they are independent path computation.For dependent request, let me clarify
your points.
- For dependent (associated) diverse path requests in a single domain, concurrent path computation
are required to meet good resource usage or maximize disjointness between diverse path pair.
- When this concept is applied across PCE domains,  downstream PCE must reply full combinations of
potential path to meet same objective above,  because final path decision would be made in upstream
PCE using BRPC procedure.
The second point was a reason why dependent diverse path request replied so much EROs (9 EROs).
Right?

If clarification above is correct, the same solution as in the independent case can be applied. This
is because downstream PCE have responsibility on optimization of own domain, not upstream PCE. So
the downstream PCE can choose suitable EROs set (just 3 EROs in section 6.2 example) based on own
policy.

Other typos will be revised in next version.

Thank you.
== Itaru Nishioka,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Filippo Cugini
> Sent: Thursday, September 03, 2009 1:47 AM
> To: [email-masked]
> Subject: Re: [Pce] Working Group Last 
> Call:draft-ietf-pce-pcep-svec-list-02.txt
> 
> Hi,
> 
> just one clarification in the case of multiple associated 
> end-to-end diverse path computations.
> Example: consider one additional end-to-end diverse path 
> computation (say Requests #3 and #4, source S2 and dest. D2) 
> associated to the diverse path computation S1-D1 reported in 
> section 6.
> The EROs computed for Req #1 and #2 (those in section 6.2) 
> may be related to the EROs computed for Req #3 and #4.
> However, if the two sets of computed EROs are independent, up 
> to 3 EROs per request would be sufficient (as in 6.2).
> Is it required to enclose in the PCRep message all the 
> combinations (even if they are independent)?
> 
> Few typos:

---

From: <[email-masked]>
Date: Wed, 9 Sep 2009 19:42:32 +0200

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-masked] [mailto:[email-masked]] On Behalf Of JP
Vasseur

Dear all,

Thanks.

JP and Julien.

---

From: "Daniel King" <[email-masked]>
Date: Wed, 9 Sep 2009 22:36:37 +0100

Thanks Julien, good comments. We will take these and Filippo's and update
accordingly. 

Br, Dan. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: 09 September 2009 18:43
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Pce] Working Group Last Call:
draft-ietf-pce-pcep-svec-list-02.txt

Hi Itaru, hi Dan.

--------------------
As recommended

Julien

-----Original Message-----

Dear all,

Thanks.

JP and Julien.

---

From: <[email-masked]>
Date: Mon, 21 Sep 2009 16:05:06 +0200

Hi all.

The Last Call for draft-ietf-pce-pcep-svec-list-02 has ended. Authors,
could please address received comments in the next revision.

Thanks,

JP & Julien

-----Original Message-----

Dear all,

Thanks.

JP and Julien.

---

From: "Itaru Nishioka" <[email-masked]>
Date: Wed, 23 Sep 2009 23:53:52 +0900

Hi Julien, and all.

Thank you for kind review and many good comments.

I have posted new version of draft (draft-ietf-pce-pcep-svec-list-03), which addressed all comments
from Julien and Filippo during the Last Call. 

Regards,
Itaru.

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Monday, September 21, 2009 11:05 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [Pce] Working Group Last Call: 
> The Last Call for draft-ietf-pce-pcep-svec-list-02 has ended. 
> Authors, could please address received comments in the next revision.
> 
> Thanks,
> 
> JP & Julien
> 
> 
> Behalf Of JP Vasseur
> 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.
>