Subject: [Pce] Working Group Last Call on draft-ietf-pce-pcecp-interarea-reqs-04.txt

From: JP Vasseur <[email-masked]>
Date: Wed, 22 Nov 2006 09:51:47 -0500

Dear WG,

A new revision of draft-ietf-pce-pcecp-interarea-reqs (rev -04) has  
been posted that addresses the remaining issues/comments.

This email initiates a Working Group Last Call on draft-ietf-pce- 
pcecp-interarea-reqs-04.txt. The last call will end on December 8th  
at noon EST.

Please send your comments to the mailing list.

Thanks.

JP.

_______________________________________________
Pce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pce

---

From: [email-masked]
Date: Wed, 29 Nov 2006 09:34:38 +0100

hi

comment on this doc.

4.5. Inclusion of Area IDs in Request 
 
   The knowledge of the areas in which the source and destination lie 
   would allow selection of appropriate cooperating PCEs. 

=> so is there an assumption that the PCE-Area ID knowledge is available - 
how come ?

   A PCE may not 
   be able to determine the location of the source and destination and 
   in such a case it would be useful that a PCC indicates the source and 
   destination area IDs. 

=> not sure to see the reasoning - i guess the initial PCE referred to 
here is an intermediate PCE that does not have any visibility of the 
source/destination areas and potentially more - the whole problem in this 
sentence is the interpretation of the term - location -
 
   For that purpose the request message MUST support the inclusion of 
   the source and destination area IDs. Note that this information could 
   be learned by the PCC through configuration. 
 
=> how to be sure that the local area PCE is going only to be contacted by 
local area PCC's - we're entering into a chicken egg problem, from one 
side mandate knowledge of source/destination area but on the other there 
is no guarantee about interpretation of this information before knowing 
the PCC - area ID relationship

4.6. Area Inclusion/Exclusion 
 
   In some situations it may be useful to include one or more area(s) in 
   the path. 

=> for inter-area it is certainly true that the actual path will cross 
multiple areas but i wonder whether what you mean is not the request 
includes one or more areas to be followed by the path to be computed 

   It may also be useful to exclude one or more area(s) from 
   the path (e.g. request for a path between LSRs in two stub areas 
   connected to the same ABR(s), which must not cross the backbone 
   area). Hence the request message MUST allow indicating a set of one 
   or more area(s) that must be explicitly included in the path, and a 
   set of one or more area(s) that must be explicitly excluded from the 
   path. 

=> be prepared to incorporate a loop avoidance mechanism, in case the 
request will have to cross multiple PCEs

other comments to follow
- d.

JP Vasseur <[email-masked]>
22/11/2006 15:51
 
        To:     [email-masked]
        cc: 
        Subject:        [Pce] Working Group Last Call on 
draft-ietf-pce-pcecp-interarea-reqs-04.txt

Dear WG,

Thanks.

JP.

---

From: [email-masked]
Date: Wed, 29 Nov 2006 09:45:09 +0100

section 4.7 Inter-area Diverse Path computation

o) wrt 6. Security Considerations "IGP areas are administrated by the same 
entity. .."

does the latter ensure uniqueness of the SRLG IDs ?

o) The response message MUST allow indicating the level of diversity of 
   a set of computed loose paths. 

do you mean partial disjointness ? or something equivalent ? 

o) last sentence §3 unclear to me wrt to the next sentence - is it 
referring to a 
diversity of a given wrt to a set of resources but the next sentence 
refers to the
diversity of a given LSP wrt to a set of other LSPs but also their SRLG 
set for inst. ?

thanks,
- d.

        To:     [email-masked]
        cc: 

Dear WG,

Thanks.

JP.