RE: [Pce] Working Group Last Callon draft-ietf-pce-pcecp-interarea-reqs-04.txt

["LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>]

Hi Dimitri,

Sorry for this late answer.
Thanks for your comments.

Please see inline, 

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] 
> Envoyé : mercredi 29 novembre 2006 09:35
> À : JP Vasseur
> Cc : [e-mail]
> Objet : Re: [Pce] Working Group Last Callon 
> 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 ?

Yes this information can be made available with the discovery protocol, see [RFC4674] section 4.1.1.2.

We can rephrase as follows:

"The knowledge of the areas in which the source and destination lie 
would allow selection of appropriate cooperating PCEs. This would be useful when the area ID(s) of a PCE (i.e. the area(s) where it has visibility) is/are known, which can be achieved by the PCE Discovery Protocol (see [RFC4674]) or any other mean."

> 
>    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 -

OK we can rephrase as follows

"A PCE in a PCE chain, may not have any visibility of the source/destination area and  hence may not be able to determine the area of the source/destination" 

>  
>    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 

Why do you need such assurance?
I don't catch your point here.

>- we're entering into a chicken 
> egg problem, from one side mandate knowledge of 
> source/destination area

We don't mandate knowledge of src/dest area. We say "the request message MUST support the inclusion", we don't say "MUST include"

> but on the other there is no 
> guarantee about interpretation of this information before 
> knowing the PCC - area ID relationship


Here we simply ask the PCECP to support the inclusion of source and destination area IDs in the request.
When this information is known by the PCC (through configuration or any other means), then it may be included in the request message, and this may facilitate selection of downstream PCEs.


> 
> 
> 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 

Yes it is, will be reworded as follows.

"It may be useful that the request message indicate one or more area(s) that must be followed by the path to be computed.
It may also be useful that the request message indicate one or more area(s) that must be avoided 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

Yes a loop avoidance mechanism will be needed, independantly of this area inclusion/exclusion by the way.
I don't think this requires any specific text here.

> 
> other comments to follow
> - d.

OK, see below,

> 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 ?

YES

> 
> 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 ? 

This refers to link, node, SRLG diversity of a set of paths.

We can add the following

"The response message MUST allow indicating the level of diversity of a set of computed inter-area loose paths (link, node, SRLG diversity), globally and on a per-area basis (link, node, SRLG diversity of intra-area path segments). 

> 
> 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. ?
> 

It refers to the diversity of a set of paths. I agree that this is not clear.

Will rephrase as follows

"It MUST allow indicating the required level of diversity of a set of inter-area paths (link, node, SRLG diversity), as well as the required level of diversity of a set of intra-area segments of inter-area paths(link, node, SRLG diversity) on a per-area basis.

Thanks a lot for your comments Dimitri.
Let us know if the proposed text is fine with you and we will submit a new revision.

Best Regards,

JL



> 
> 
> 
> 
> JP Vasseur <[e-mail]>
> 22/11/2006 15:51
>  
>         To:     [e-mail]
>         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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pce
> 
> 
> 
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pce
> 

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