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

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 11 Oct 2005 10:59:25 +0200

Hi Adrian

Please see inline 

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Adrian Farrel
> Envoyé : mercredi 5 octobre 2005 22:51
> À : Ash, Gerald R (Jerry), ALABS; [email-masked]
> Objet : Re: [Pce] RE: I-D 
> ACTION:draft-ietf-pce-comm-protocol-gen-reqs-02.txt
> 
> 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. 

Agree, today no

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

Agree, but in this case we should not presume any semantic.
The term cost refers IMHO to a particular semantic. This is more
related to an optimization criteria i.e. an objectivie function ( Computation of shortest cost path) than a path constraint.
Computing a "cost bounded path" does not really make sense IMO...

Given that at the time being as we don't have specific link attributes to encode path attributes such as delay, distance, power loss, polarization and so one, I would suggest that we say:

"
- Maximum end-to-end IGP metric 
- Maximum end-to-end TE metric 

where the IGP or TE metric may represent any additive aggregate path attribute (e.g. delay, power loss...)"

Best Regards,

JL

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

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

---

From: "LE ROUX Jean-Louis RD-CORE-LAN" <[email-masked]>
Date: Tue, 11 Oct 2005 11:02:42 +0200

Hi Igor,

Please see inline, 

> [mailto:[email-masked]] De la part de [email-masked]
> Envoyé : vendredi 7 octobre 2005 14:34
> À : [email-masked]
> Cc : Gerald; [email-masked]; [email-masked]
> 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 agree with you, if we find that having two aggregate path attributes (IGP metric and TE-metric) is not enough to support various constraints and optimizaiton criteria we may define new TE link sub-TLVs, potentially with a specific semantic (distance, delay, power loss...)

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

In some cases the PCE does not need to be aware of the exact semantic of a link metric, and could just apply a numeric constraint.
But I agree with you that for certain constraints (e.g. polarization, power loss...) the PCE may have to account for the exact semantic of the constraints to compute accurate paths. 

Best Regards,

JL

> Igor
> 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.
> >
> 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.
> >
> > ...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
> http://www.ietf.org/internet-drafts/draft-ietf-pce-comm-protocol-gen-r
> > eq
> > s-02.txt.
> >
> > 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 
> > Our objective is to start a WG last call soon.  We look forward to 
> > your review and comments.
> >
> > Thanks,
> > Regards,
> > Jerry
> >
> >

---

From: "Ash, Gerald R \(Jerry\), ALABS" <[email-masked]>
Date: Wed, 12 Oct 2005 11:30:06 -0500

Hi Adrian,

> Correct me if I am wrong, but delay is not a standard link parameter
> 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.
> 
> 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
> to [RFC3785] the IGP metric may be used to indicate a per link
> delay metric.

Your comments and suggested change to Section 6.1.16 make sense to me.

Thanks,
Jerry