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

[[e-mail]]

hi jean-louis

i think we're converging beside one point about section 4.5 & 4.6 
as indicated here below 

edit: on the SRLG comment for ensuring some level of consistency 
identifiers should assigned and allocated from the same entity - 
this would solve the issue mentioned

thanks,
- d.





"LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
19/12/2006 00:48
 
        To:     <[e-mail]>
        cc:     [e-mail]
        Subject:        RE: [Pce] Working Group Last    Callon 
draft-ietf-pce-pcecp-interarea-reqs-04.txt


Hi Dimitri,

Thanks for these clarifications.

Please see in-line, 

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] 
> Envoyé : lundi 18 décembre 2006 10:25
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [e-mail]; JP Vasseur; [e-mail]
> Objet : RE: [Pce] Working Group Last Callon 
> draft-ietf-pce-pcecp-interarea-reqs-04.txt
> 
> hi jean-louis
> 
> see in-line for a couple of clarifications
> 
> 
> 
> 
> "LE ROUX Jean-Louis RD-CORE-LAN" <[e-mail]>
> 15/12/2006 19:29
> 
>         To:     <[e-mail]>, 
> "JP Vasseur" 
> <[e-mail]>
>         cc:     <[e-mail]>
>         Subject:        RE: [Pce] Working Group Last Callon 
> draft-ietf-pce-pcecp-interarea-reqs-04.txt
> 
> 
> 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?
> 
> [dp] because the PCC itself may be an area where PCE learning 
> and PCC learning are not identical (PCC knows less than the PCE)

Again, we don't mandate the inclusion of source/dest area IDs in any 
request.
In situations where the PCC is aware of this information this may be 
useful to include it in the request. 

> 
> I don't catch your point here.
> 
> [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

If the request includes the destination area, then the PCE becomes aware 
of it, it can then select a downstream PCE based on advertised PCE 
information (PCE areas).



> 
> >- 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.
> 
> [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, we can add the following section

4.9 Loop Avoidance

In case of multiple-PCE inter-area path computation there may be risks of 
PCECP request loops.
A mechanism MUST be defined to detect and supress PCECP request message 
loops. This may rely, for instance, on the recording, in the request 
message, of the set of traversed PCEs. 
Also the returned path in a response message MUST be loop free.

Would such a section make sense to you?


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

But when you build SRLGs for an IP network you also account for the ducts.
By the way you can be aware of the duct that is actually used, even if the 
fiber is rent (this can be provided in the contract).

Anyway, a requirement for SRLG diverse path computation makes the 
assumption of consistent SRLGs...and there is nothing specific to the PCE 
nor to the inter-area case here.

Thanks,

JL



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



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