6 Aug 2009 18:43
IETF-75 Draft PCE Minutes
Daniel King <daniel <at> olddog.co.uk>
2009-08-06 16:43:23 GMT
2009-08-06 16:43:23 GMT
Hello PCE’rs,
The draft minutes for our IETF-75 meeting have been uploaded to:
http://www.ietf.org/proceedings/75/minutes/pce.html
Please suggest any corrections by August 21, 2009.
Br, Dan.
<div> <div class="Section1"> <p class="MsoPlainText">Hello PCE’rs,<p></p></p> <p class="MsoPlainText"><p> </p></p> <p class="MsoPlainText">The draft minutes for our IETF-75 meeting have been uploaded to:<p></p></p> <p class="MsoPlainText"><p> </p></p> <p class="MsoPlainText"><a href="http://www.ietf.org/proceedings/75/minutes/pce.html">http://www.ietf.org/proceedings/75/minutes/pce.html</a><p></p></p> <p class="MsoPlainText"><p> </p></p> <p class="MsoPlainText">Please suggest any corrections by August 21, 2009. <p></p></p> <p class="MsoPlainText"><p> </p></p> <p class="MsoPlainText">Br, Dan. <p></p></p> <p class="MsoNormal"><p> </p></p> </div> </div>
This requirement was in the draft (dated May 2008) that the working group
accepted as a working group document.
> Basically that means encoding a new opaque to PCEP field (for
> instance in a new object or TLV) that would be pass to PCE
> policy module.
> Is that correct?
I don't think it has to be like that.
I think a number of the PCEP data are transparent, but are still passed to
(optionally) to the PCE policy module. Is this PCC allowed to request this
type of computation for this type of service? Reoptimization is more subtle
than initial computation because it can disrupt traffic. So reoptimization
can also be subject to policy on the PCE relating to by how much a
computation must be "better" than the in-place path, before the new path is
returned to the requester.
In RFC 5440, we deal with reoptimization of individual drafts. The METRIC
object contains the B flag. This allows the PCC to effectively set a
reoptimization threshold - and the value supplied could be less than the
value of the actual path.
Reoptimizing a single P2MP LSP is like a cross between RFC 5440 and RFC
5557. There is only one LSP, but there are multiple destinations. As for the
first computation, the PCC needs to be able to indicate how the LSP is to be
optimized (e.g., shortest path to detination, least cost tree, etc.), but
since the LSP is already in place and reoptimization of one factor may make
another factor worse, there will be a trade-off. Thus, the reoptimization
request needs to be able to guide the PCE as to which factors to reoptimize
for and what are the acceptable variations of the other factors.
Additionally, as for the p2p case, an optimization of a very small
percentage may be considered unwise.
All of these P2MP parameters, just like any other PCEP parameter, is subject
to policy at the PCE. The PCE is likely to be aware of network policies and
the concept of "fareness". It may protect the other PCCs against a greedy
PCC, and it may protect the network against instability.
> 2.1.11.
> " It MAY also be possible to indicate on a path computation request a
> cost-benefit reoptimization threshold such that the tree and/or a new
> path to any individual destination is not supplied unless a certain
> improvement is made. Compare with Section 2.1.10."
>
> Does it mean that a PCE may deny the addition of a leaf because the tree
> does not provide certain improvement?
> Or do you rather mean that the PCE would not change the existing Path
> unless
> it provides certain improvment?
>
> I guess second option makes more sense. If correct I would suggest
> something
> like:
> "The addition of new leaves will not cause reoptimization of the existing
> P2MP tree unless a certain improvement is made."
Yes, the original wording is broken.
Your suggestion is good.
This paragraph now reads...
It MAY also be possible to indicate on a path computation request a
cost-benefit reoptimization threshold such that the addition of new
leaves will not cause reoptimization of the existing P2MP tree unless
a certain improvement is made over simply grafting the new leaves to
the existing tree. (Compare with Section 2.1.10.)
Cheers,
Adrian
> On Thu, Aug 20, 2009 at 4:46 PM, Adrian Farrel <adrian <at> olddog.co.uk>
> wrote:
>
>> Hi,
>>
>> This revision only updates references and authors' coordinates.
>>
>> The authors believe that this work is pretty much done, but we are
>> waiting
>> for the protocol extensions to stabilise.
>>
>> We would welcome review input and especially comments from the people
>> working on the protocol extensions. Have we explained all of the
>> requirements clearly? have you come across anything else that we haven't
>> captured?
>>
>> Thanks,
>> Adrian
>> ----- Original Message ----- From: <Internet-Drafts <at> ietf.org>
>> To: <i-d-announce <at> ietf.org>
>> Cc: <pce <at> ietf.org>
>> Sent: Thursday, August 20, 2009 3:30 PM
>> Subject: [Pce] I-D Action:draft-ietf-pce-p2mp-req-02.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Path Computation Element Working Group
>>> of
>>> the IETF.
>>>
>>>
>>> Title : PCC-PCE Communication Requirements for Point to
>>> Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)
>>> Author(s) : S. Yasukawa, A. Farrel
>>> Filename : draft-ietf-pce-p2mp-req-02.txt
>>> Pages : 10
>>> Date : 2009-08-20
>>>
>>> The Path Computation Element (PCE) provides path computation
>>> functions in support of traffic engineering in Multi-Protocol Label
>>> Switching (MPLS) and Generalized MPLS (GMPLS) networks.
>>>
>>> Extensions to the MPLS and GMPLS signaling and routing protocols have
>>> been made in support of point-to-multipoint (P2MP) Traffic Engineered
>>> (TE) Label Switched Paths (LSPs). The use of PCE in MPLS networks is
>>> already established, and since P2MP TE LSP routes are sometimes
>>> complex to compute, it is likely that PCE will be used for P2MP LSPs.
>>>
>>> Generic requirements for a communication protocol between Path
>>> Computation Clients (PCCs) and PCEs are presented in "Path
>>> Computation Element (PCE) Communication Protocol Generic
>>> Requirements". This document complements the generic requirements and
>>> presents a detailed set of PCC-PCE communication protocol
>>> requirements for point-to-multipoint MPLS/GMPLS traffic engineering.
>>>
>>> A URL for this Internet-Draft is:
>>> 
RSS Feed