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

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 <jvasseur@cisco.com>
22/11/2006 15:51

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

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
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce

_______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/pce