Subject: [Pce] Re: WG Review: Path Computation Element (pce)

From: Pekka Savola <[email-masked]>
Date: Tue, 4 Jan 2005 23:23:59 +0200 (EET)

On Thu, 23 Dec 2004, The IESG wrote:
> A new IETF working group has been proposed in the Routing Area.  The IESG
> has not made any determination as yet. The following description was
> submitted, and is provided for informational purposes only. Please send
> your comments to the IESG mailing list ([email-masked]) by December 30th.

The deadline is already past, but here's my couple of cents.

In short, I think the WG is tasked with a lot of work items, with no 
clear priorization and/or requirement for the order in which this work 
is to be conducted.  I fear this would result in a rush to get the 
protocols out, with little regard to thinking about the requirements 
and the framework.

> The PCE Working Group is chartered to specify a Path Computation Element
> (PCE) based architecture for the computation of paths for MPLS and GMPLS
> Traffic Engineering LSPs.
>
> In this architecture path computation does not occur on the head-end
> (ingress) LSR, but on some other path computation entity that may
> physically not be located on the head-end LSR.

This seems like useful work, and the same concept could be applied to 
a lot of other uses as well if it proves a success here (e.g., 
intserv-like QoS, soBGP/sBGP).  However, to focus the work, let's just 
look at this narrowly now.

It might make sense to s/Path/MPLS-TE Path/ in the WG name.

> Work Items:
>
> - Functional specification of MPLS and GMPLS Traffic Engineered LSP path
> computation models involving Path Computation Element(s). This
> includes the case of computing the paths of intra and inter-domain
> TE LSPs. Such path computation includes the generation of primary,
> protection and recovery paths, as well as computations for (local/global)
> reoptimization and load balancing. The WG will address the inter-area
> (single IGP domain) scenario first. WG progress will be evaluated before
> inter-AS related work is started.
>
> - Specification of the PCE-based architecture.

These are good topics.

> - Specification of requirements and protocol extensions related to
> the policy, and security aspects of PCE-based path computation involving
> PCEs of multiple administrative entities.

It might make sense to focus first on the requirements part only.

> - In cooperation with protocol specific Working Group (OSPF, ISIS, IDR,
> MPLS, CCAMP), development of routing (OSPF, ISIS, BGP) and LSP
> signaling (RSVP-TE) extensions required to support PCE-based path
> computation models.
>
> - Specification of techniques in support of PCE discovery within and
> across domains. Where such techniques result in the extensions of
> existing protocols (OSPF, ISIS and BGP), this work will be done in
> conjunction with the appropriate WGs.
>
> - Specification of a new communication protocol for use between a PCC
> and a PCE, and between PCEs. A single protocol will be selected from
> among candidates that include the existing protocols defined in other
> WGs.

These are presumptive of the approach for the solution, and I'm not 
sure if it makes good sense to include these at this point in the 
charter, at least without a disclaimer that these will be worked on 
later.

For example, the second bullet presumes the PCE discovery would be 
done using a routing protocol.  The discovery might be done using a 
completely different kind of protocol, or just using manual 
configuration.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 7 Jan 2005 00:01:36 -0000

Hi Pekka,

As you say, the deadline is past, but that doesn't stop the chairs (if a
WG is formed) being sensitive to the points you raise and carrying them
forward into the operation of the WG.

See in line.

Cheers,
Adrian

> protocols out, with little regard to thinking about the requirements

IMHO the milestones give a clear prioritization. In these matters I would
hope that we can depend on the chairs to ensure that an appropriate
ordering is followed. The ADs will (of course) be watching.

> look at this narrowly now.

Absolutely. And you'll notice that first off we are significantly limiting
the scope even within the bounds of (G)MPLS-TE LSPs.

> It might make sense to s/Path/MPLS-TE Path/ in the WG name.

Well may be. What's in a name?

> > Work Items:

[SNIP]

> It might make sense to focus first on the requirements part only.

If only requirements are in the charter, one might ask why both with
requirements?
Thus solution is also in charter, but we would assume that the focus would
be on the requirements first. See the milestones.

> charter, at least without a disclaimer that these will be worked on

I don't believe they make this presumption at all.
There is a presumed architecture (this was a requirement before the
charter was drafted) and this places certain assumptions on the solution:
- there will be a communication between PCC and PCE
- PCE discovery is needed
- every attemot will be made to re-use existing routing
  and signaling protocols used to establish TE LSPs
- the current routing and signaling protocols MIGHT NOT
  be adequate to support TE LSP establishment in the
  presence of PCE.

> completely different kind of protocol, or just using manual

No, it doesn't say this at all.
It says "Where such techniques result in the extensions of existing
protocols..." which acknowledges that discovery might use a routing
protocol, but doesn't say it must. This text is important because we do
not want a PCE WG modifying the routing protocols without consultation
with the WG that owns the protocol.

---

From: Pekka Savola <[email-masked]>
Date: Sat, 8 Jan 2005 21:57:10 +0200 (EET)

> ordering is followed. The ADs will (of course) be watching.

This may be one approach, but builds on the WG chair being able to 
convice the WG that the proposed priorization is in fact the right 
one.  This seems optimistic, as the WG participants are very likely 
eager to jump to the solutions already :).

I've seen many WGs stumble because the charter did not restrict and 
guide the steps of the WG well enough.   Such a charter is easier for 
the WG chairs as well because they have concrete levers they can pull 
to justify working in a specific order.

> be on the requirements first. See the milestones.

Yes, one would hope so.  As I write above, it would make the job of 
the WG and WG chairs (and ultimately the ADs) easier if this 
assumption was clearly written in the charter, maybe as a requirement 
how the work should be done.

>>> conjunction with the appropriate WGs.
[...]
>  be adequate to support TE LSP establishment in the

OK.  However, the second bullet was the one that struck me as 
requiring wordsmithing, below...

> with the WG that owns the protocol.

The text says:

"Specification of techniques in support of PCE discovery within and 
across domains. Where such techniques result in the extensions of 
existing protocols (OSPF, ISIS and BGP), this work will be done in 
conjunction with the appropriate WGs."

The implication seems to be: ".. existing _routing_ protocols (OSPF, 
ISIS, and BGP)".

Is PCE discovery, requiring extensions to existing non-routing 
protocols (e.g., DNS) off the table?

I.e., the text seems to assume that "protocol" == "routing protocol".

---

From: Alex Zinin <[email-masked]>
Date: Mon, 10 Jan 2005 17:29:52 -0800

Pekka, Adrian-

Pekka, first thanks for actually reviewing the charter and providing your
comments. Reading is such a rare quality these days ;)

The IESG discussed this last thursday. Inline comments below.

> to justify working in a specific order.

Both WG chairs and ADs were comfortable with using milestones as the means
of prioritization. The IESG was also fine with this.

> conjunction with the appropriate WGs."

The IESG thought that my suggestion to tweak the wording a bit to say "(e.g.
OSPF, ISIS, or BGP)" would address this problem as long as there's understanding
that there's no such presumption, which is the case, I believe.

Where we are with the charter now: the charter is tentantively approved, the
secretariat expects the final text tweaks and a go-ahead from me, which is when
they will send out the announcement.

Alex