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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Fri, 15 Dec 2006 19:29:26 +0100

Hi Dimitri,

Sorry for this late answer.
Thanks for your comments.

Please see inline, 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] 
> Envoyé : mercredi 29 novembre 2006 09:35
> À : JP Vasseur
> Cc : [email-masked]
> 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 <[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,
> 
> 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
> 
> 
> 
> _______________________________________________
> Pce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pce
> 

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

---

From: [email-masked]
Date: Mon, 18 Dec 2006 10:25:12 +0100

hi jean-louis

see in-line for a couple of clarifications

"LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
15/12/2006 19:29
 
        To:     <[email-masked]>, "JP Vasseur" 
<[email-masked]>
        cc:     <[email-masked]>
        Subject:        RE: [Pce] Working Group Last Callon 
draft-ietf-pce-pcecp-interarea-reqs-04.txt

Hi Dimitri,

Please see inline, 

> is available - how come ?

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

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

[dp] because the PCC itself may be an area where PCE learning and PCC
learning are not identical (PCC knows less than the PCE)

[dp] but this can also happen in the other way around, the issue is 
that this information is provided as helper to the PCE looking at the
different cases we've at hand even if this information is provided it
does not still guarantee that the "local PCE" will be able to determine
the location of the destination and hence the next/downstream PCE

> egg problem, from one side mandate knowledge of 

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

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

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

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

[dp] shouldn't that specific text be included in the document, as it is 
meant to cover both PCC-PCE and PCE-PCE messaging ?

OK, see below,

YES

[dp] in theory yes, in practice not - just think upon the case where a 
single entity borrows fibers from two different plants each of them having 
chosen different SRLG IDs for two fibers lying in the same duct - 

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

> given LSP wrt to a set of other LSPs but also their SRLG set 

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