Subject: [Pce] Proposed Charter for a PCE WG

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 8 Oct 2004 23:32:32 +0100

Hi,

The main purposes of the PCE BOF in Washington DC will be to discuss the PCE architecture,
and the need for and scope of a PCE WG. Hence the proposed charter is particularly
important.

JP and I have put together the following as a starting point, and we would very much
appreciate your comments on the mailing list in advance of the meeting. Specific
milestones are pending agreement on the major work areas.

Thanks,
Adrian
============
Proposed Charter

WG items:
- Functional specification of Generalized Traffic Engineered LSP path
  computation techniques involving Path Computation Element(s). This
  includes the case of intra IGP area, inter IGP area, inter-AS and
  inter-provider TE LSPs path computation for both Point to Point,
  Point to Multipoint and Multipoint to Multipoint TE LSPs.
- Specification of routing (OSPF, ISIS, BGP) and signaling (RSVP-TE)
  extensions required by PCE-based path computation techniques.
  Specification of routing extensions in support of PCE discovery
  techniques within an IGP area and across multiple IGP areas, ASes
  and Provider networks. The proposed extensions will done in
  conjunction with the WGs in charge of the specification of those
  protocols.
- Specification of new protocols or modifications to existing
  protocols to facilitate communication between LSRs and PCEs, and
  between a PCE and other PCEs.
- Definition of protocol-independent metrics defining path quality
  measurement criteria, algorithm complexity and scalability criteria
  related to path computation techniques.
- Specification of requirements and protocol extensions related to the
  policy, security and confidentiality aspects of PCE-based path
  computation techniques involving PCEs of multiple Providers.
- Definition of MIBs and management procedures related to the new
  protocols, protocol extensions and operational elements defined
  by the WG.

The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and will
also cooperate with the ITU-T and OIF where appropriate.

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

---

From: Kenji Kumaki <[email-masked]>
Date: Fri, 15 Oct 2004 13:57:30 +0900

Hi JP and Adrian,

I agree with this proposed charter.

Is PCE-based path computation in Multi-layer network environment within
this charter?

Regards,
Kenji

On Fri, 8 Oct 2004 23:32:32 +0100

-- 
Kenji Kumaki <[email-masked]>

---

From: Kohei Shiomoto <[email-masked]>
Date: Fri, 15 Oct 2004 15:11:25 +0900

Hi Kenji

It is a good point.

I would suggest that the list of scenarios for the functional 
specification of PCE techniques should also include inter-region (that 
is, between GMPLS switching regions) and inter-layer (that is, between 
layers of a multi-layer network).

Thanks,
--
Kohei Shiomoto

-- 
Kohei Shiomoto, Ph.D
NTT Network Service Systems Laboratories
3-9-11 Midori, Musashino, Tokyo 180-8585, Japan
Phone +81 422 59 4402    Fax +81 422 59 4549

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 15 Oct 2004 10:33:11 +0200

hi adrian, jp,

>   Point to Multipoint and Multipoint to Multipoint TE LSPs.

-> when you say "both" to what does it apply in the above sentence ?

-> this item uses a terminology related to the partitioning of the
    network in terms of routing instead of PCE responsibility scope -
    so should i consider this as part of the work to disambuiguate the
    situation ?

-> is it expected as part of this item to deliver the functionality
    for "segment" computation for a given path p2p, p2mp or mp2mp LSP ?
    as this is not explicitly indicated

>   extensions required by PCE-based path computation techniques.

-> would you clarify the implication of RSVP-TE in path computation
   "techniques" ? as there are no resource reservation expected here

    if the intent is to say "result of computation should be usable by
    signaling protocols used to setup the LSP along the computed path"
    i think this would better translate implication of RSVP-TE

>   conjunction with the WGs in charge of the specification of those

-> there should be an explicit item detailing what are the potential
    PCE discovery techniques are/or involved mechanisms b/f discussing
    for routing extensions (as routing is not the only means to achieve
    this anyway)

-> which WG wrt to RSVP-TE as mentioned here above (note: OSPF, ISIS
    and BGP have an associate WG) - RSVP(-TE) does not or do we assume
    implicitly it is the CCAMP WG ?

>   between a PCE and other PCEs.

-> the term LSR is imho not accuarate enough - also referring to the
    discussion wrt to FORCES - i think there is the need to introduce
    the term PC Requestor, Client or equivalent (instead of LSR) to
    avoid further confusion and ensure genericity

>   computation techniques involving PCEs of multiple Providers.

-> why only multiple providers would be involved in this item ? why not
    PCEs of multiple administrative entities ?

> also cooperate with the ITU-T and OIF where appropriate.

-> as BGP is part of the protocols in the loop, IDR should also be
    listed as part of the above list of WGs
   _______________________________________________
> .

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 15 Oct 2004 13:33:03 +0100

Hi Dimitri,

Thanks for your comments...

> -> when you say "both" to what does it apply in the above sentence ?

It refers to JP's inability to speak English, and my laziness when reviewing the draft :-)

"both" should read "each of" and applies to P2P, P2MP and MP2MP LSPs.

>     so should I consider this as part of the work to disambuiguate the
>     situation ?

Agreed. We are struggling to avoid a circular definition because PCE is clearly
responsible for computing paths in the set of nodes for which PCE is responsible for
computing paths. The set of possible computational domains is not intended to be
exhaustive, but perhaps we should try to generalize the description by using
"computational domain", and describing intra and inter-domain computation.

>     as this is not explicitly indicated

Unclear whether you mean segment as in a stitchable segment, or segment as in a protection
segment (or both). In any case, yes this is intended to be included.

I am not sure whether the charter at this stage should attempt to list each detailed item,
or whether it should list a task to discover and document the detailed items.

>     i think this would better translate implication of RSVP-TE

In my mind I have the ability to signal (to, for example, an ASBR) the identity of a PCE
and the key of a computed path so that the ASBR can retrieve the next segment of a
precomputed path that has not be signalled across the first AS because of confidentiality
concerns. This would require a signaling extension to support a PCE-based path computation
technique.

>     for routing extensions (as routing is not the only means to achieve

I agree. We have got ahead of ourselves. This item might read better as:
   Specification of techniques in support of PCE discovery within and
   across IGP areas, ASes and Provider networks. Where such
   techniques result in the extensions of existing protocols, this work
   will be done in conjunction with the appropriate WGs.

>     implicitly it is the CCAMP WG ?

TBD (and pending discovery that that work is needed)

>     avoid further confusion and ensure genericity

Yes. We have PCC, and should use that term.

>     PCEs of multiple administrative entities ?

Agreed.

>     listed as part of the above list of WGs

Agreed.

Thanks,
Adrian

---

From: dimitri papadimitriou <[email-masked]>
Date: Sat, 16 Oct 2004 16:50:39 +0200

> "both" should read "each of" and applies to P2P, P2MP and MP2MP LSPs.

ok -

> "computational domain", and describing intra and inter-domain computation.

ok - i think by generalizing the description by using "computational 
domain" it would definitelly clarify the situation

> segment (or both). In any case, yes this is intended to be included.

it was meant to cover the former (but in fact this case includes the 
latter because the computation of protecting segment taking into account 
protected segment path properties is a particular case of constraint) 
should even have better referred to this as intermediate segment 
computation - the reason is to avoid focusing only on full end-to-end 
path computation (from sender to receiver) that is a particular case

> or whether it should list a task to discover and document the detailed items.

you are right here that the definition of a taxonomy and classification 
of each of the detailed items is the initial and primary objective to be 
achieved

> concerns. This would require a signaling extension to support a PCE-based path computation

so the idea here would be to use the signaling to trigger the inclusion 
from a PCE along the LSP path of a computed segment but for which 
details are not known to the initiator of the request ? this would 
translate to an extension of the so-called constrain-passing model where 
you have an additional constraint in terms of computation element as 
long as the method is integrated as part of signaling information 
exchange for resource reservation purpose towards the LSP destination

>    will be done in conjunction with the appropriate WGs.

ok - it clarifies

> TBD (and pending discovery that that work is needed)

ok - i see that this important question which is not "PCE-specific" at 
the end is also likely to

> Yes. We have PCC, and should use that term.

ok -

>>    PCEs of multiple administrative entities ?

ok -

>>>The WG will work closely with the following other WGs: CCAMP, MPLS, ISIS, OSPF; and
>>> will also cooperate with the ITU-T and OIF where appropriate.
>>

ok -

thanks,
- dimitri.

---

From: Olivier Bonaventure <[email-masked]>
Date: 19 Oct 2004 09:44:31 +0200

Adrian and JP,
> and the need for and scope of a PCE WG. Hence the proposed charter is particularly

I think that the problem addressed by the PCE BOF is important and
justifies a WG. The proposed charter is ambitious as it covers a wide
range of problems.

Do you have ideas on the expected timing for each work item ?

>also cooperate with the ITU-T and OIF where appropriate.

How do you envision the cooperation with the other IETF WGs ?
PCE proposes requirements and waits for answer from responsible WG or
PCE defines requirements and proposes solution which is jointly approved
by PCE and the responsible WG ?

Best regards,

Olivier

---

From: JP Vasseur <[email-masked]>
Date: Tue, 19 Oct 2004 08:12:54 -0400

Hi Oliver,

> justifies a WG. The proposed charter is ambitious as it covers a wide

Thanks.

> Do you have ideas on the expected timing for each work item ?

We're currently working on the milestone, should a WG be formed, and we 
will share it with the list.

> How do you envision the cooperation with the other IETF WGs ?

Yes, this will be listed in the proposed WG charter.

> by PCE and the responsible WG ?

The later.

Thanks.

JP.