Subject: Re: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 5 Oct 2005 21:51:15 +0100

Thanks Jerry and team,

A question about section 6.1.16 of this draft.

Here it says...

   Here is the list of generic constraints that MUST be supported:

   o MPLS-TE and GMPLS generic constraints:
     - Bandwidth
     - Affinities inclusion/exclusion
     - Link, Node, SRLG inclusion/exclusion
     - Maximum end-to-end delay metrics
     - Hop Count
     - Maximum end-to-end TE metric (cost)
     - Multiple disjoint path computation to allow path protection

Correct me if I am wrong, but delay is not a standard link parameter
exchanged by the TE IGPs. Instead, we have RFC 3785 that suggests that a
network may be operationally configured so that the IGP metric has one
meaning, and the TE metric another meaning. Further, it suggests that a
use might be to place a delay metric in the IGP metric field.

Certainly, therefore, if a network is operated according to RFC 3785 and
the IGP metric is interpreted as a delay metric a PCE will understand how
to constrain the path computation according to a delay bound. But if the
network is operated in any other way, the PCE will not be able to act on
the delay constraint. Further, if the network is operated in some other
way, the PCC will not be able to request that the path is constrained
according to the two metrics advertised by the TE IGP.

Wouldn't it be more sensible to require that support of:
     - Maximum end-to-end IGP metric (cost)
     - Maximum end-to-end TE metric (cost)

...and add a note that if the network is operated according to [RFC3785]
the IGP metric may be used to indicate a per link delay metric.

Cheers,
Adrian
----- Original Message ----- 
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 22, 2005 1:01 PM
Subject: [Pce] RE: I-D ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt

Hi All,

Please review and comment on the updated version of the PCE
communications protocol (PCECP) generic requirements I-D
http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-req
s-02.txt.

The changes include those listed on slide 3 of the Paris meeting:
http://www3.ietf.org/proceedings/05aug/slides/pce-2/sld3.htm
and responses to Adrian's comprehensive review sent to the design team
(these are all editorial comments).

The most substantive changes are the inclusion of "boundary number"
thresholds in Section 6.1.15 (Scalability).  Dimitri suggested back in
July http://www1.ietf.org/mail-archive/web/pce/current/msg00272.html
that boundary numbers be specified, and it was agreed at IETF-63 to
include 'order-of-magnitude' values in the updated draft.  This has been
done in the submitted update, and JP requested comments on this Section
in his posting 2 days ago
http://www1.ietf.org/mail-archive/web/pce/current/msg00418.html.

Our objective is to start a WG last call soon.  We look forward to your
review and comments.

Thanks,
Regards,
Jerry

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

---

From: [email-masked]
Date: Fri, 7 Oct 2005 08:33:36 -0400 (EDT)

Adrian,

What you are suggesting is reasonable and does not require changes in
IGP-TE. However, it is too general. Why not to consider introducing more
TE LINK sub-TLVs, for example, metric associated with delay introduced by
the link?

I personally believe that *all* pce constraints should be bound by
evaluating formulas to corresponding TE advertising, so that if you need
to support a new PCE constraint (whether it is a link type or path type
constraint) network TE links should advertise appropriate piece of
information. This is the only way how PCE can act on the constraint
without guessing on TE metric values.

Cheers,
Igor