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,

> 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

Ok

I'm going to submit v05 that accounts for your comments

Thanks

JL

 

> -----Message d'origine-----
> De : [e-mail] 
> [mailto:[e-mail]] 
> Envoyé : samedi 23 décembre 2006 00:17
> À : LE ROUX Jean-Louis RD-CORE-LAN
> Cc : [e-mail]
> Objet : RE: [Pce] Working Group Last Callon 
> draft-ietf-pce-pcecp-interarea-reqs-04.txt
> 
> 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