Subject: PCE Requirement in CCAMP

From: JP Vasseur <[email-masked]>
Date: Fri, 12 Aug 2005 11:41:06 -0400

Dear WG,

CCAMP proposed to work on GMPLS requirements for PCE as necessary.

Considering the work which has been done by the PCE WG on  
requirements, it
looks now more natural to move this work exclusively to the PCE WG.

That said, since Inter-domain (G)MPLS TE falls under the scope of CCAMP,
any requirements for PCE-based Inter-domain LSP computation should be
discussed in the PCE WG *with* the review of the CCAMP WG.

Similarly, non-packet networks may result in specific additional
requirements for PCE. We propose that these requirements are also raised
within the PCE working group and reviewed by CCAMP.

Let us know if you have any opinion on or objection to these proposals.

JP and Adrian (wearing PCE chair hat)

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 12 Aug 2005 18:15:37 +0200

hi jp, adrian

it depends on the perspective, as such this document is meant to address 
the following item of the charter (last part)

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

therefore, it was my understanding that the PCE WG would be waiting for 
the need wrt signaling for detailing its applicability; you (and adrian) 
seems to say we will define the requirement for PCE-based inter-domain 
path computation and resulting signaling behaviour/mechanisms would then 
need to be adapted in CCAMP

in brief, with your proposal PCE WG would be entering into a mode where 
the computational capabilities are going to drive LSP signaling itself, 
as an analogy RSVP-TE operations are decoupled from the routing 
topology; so here, the same relationship should be kept with respect to 
the computational scope/capabilities and behaviour of PCE(s)

thanks,
- dimitri.

JP Vasseur wrote:

> Considering the work which has been done by the PCE WG on  requirements, it
> .

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 12 Aug 2005 19:08:56 +0100

Hi Dimitri,

> signaling (RSVP-TE) extensions required to support PCE-based path

No, it is not meant to address that part of the charter. That item remains
unchanged by this discussion.

JP's email is clearly specific to the documentation of requirements for
PCE placed by the GMPLS protocols and non-packet networks under the
control of GMPLS protocols.

Our proposal is to develop all requirements for PCE within the PCE working
group with review by the appropriate external working group.

In practice, this only a small change since it is likely to be the same
people involved in the work. It is, however, a formal change in CCAMP
which previously had a commitment to work on these requirements.

> the computational scope/capabilities and behaviour of PCE(s)

If you are objecting to the specific item on the PCE charter then now may
be a little late, but let me explain the sort of thing that the charter
item is intended to cover by giving a couple of examples.

- PCE discovery may be achieved through the presence of
  information withing IGP advertisements. This would require changes
  to the IGPs and such changes MUST be reviewed by the
  appropriate WGs.

- The use of a fully computed path that crosses multiple domains
  raises confidentiality issues. These issues can be solved by
  inserting new sub-objects into an RSVP-TE Explicit Route
  object (for example a cookie and PCE ID, or an encrypted
  hop).

The normal way in which such small protocol changes are made (witness
GMPLS additions to the IGPs) is either:
a. An I-D is written and taken to the "owning" WG
b. An I-D is written in the WG that needs the solutions and
   is reviewed in the "owning" WG.
This process is usually refered to as "cooperation between WGs".
The PCE charter proposes business as usual.

Thanks,
Adrian

requirements, it

---

From: dimitri papadimitriou <[email-masked]>
Date: Fri, 12 Aug 2005 20:59:39 +0200

hi adrian

i perfectly understand the need from the PCE perspective but that's not 
the real question (even if one might question under which charter item 
this work would be initiated - something not clear to me from your reply 
here below)

the real issue is that with such proposal PCE WG would be entering into 
a mode where the computational capabilities are going to drive LSP 
signaling itself - please note here the difference with the discovery 
process through IGP extensions that is going to be put in place - but 
the impact of the global PCE architecture on the independence wrt path 
computation of the RSVP-TE protocol; hence, i always thought that the 
CCAMP WG would have initially provided "guidelines" to the PCE WG before 
such work would start in the PCE WG

i hope you see that the issue is not about the "owning WG" or the 
"reviewing WG" or their cooperation but the need to know more about the 
acceptable level of integration/cooperation of the PCE architecture with 
the operations on signaling LSP before deciding from where the wind will 
come from

hope this clarifies (at least a bit),
- dimitri.

Adrian Farrel wrote:

>>>That said, since Inter-domain (G)MPLS TE falls under the scope of
> 
> CCAMP,
> 
>>>requirements for PCE. We propose that these requirements are also
> 
> raised
> 
>>>Let us know if you have any opinion on or objection to these
> 
> proposals.
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 13 Aug 2005 15:34:52 +0100

Hi Dimitri,

GMPLS and non-packet requirements for PCE are likely to include the
specification of protection types, switching types, encoding types,
optical constraints, and so forth. While you could argue that CCAMP has
best knowledge of these items, it does not seem to me to matter if the
corresponding requirements I-D (that describes what constraints PCE must
be able to receive and satisfy) is developed in the PCE working group.

The question that JP's email asks is: "Is it OK with the CCAMP WG if that
requirements I-D is developed in the PCE WG with review from the CCAMP
WG?"

If we can answer this question in isolation of your other point, this
would be helpful. We can then move on to discuss you other point as
follows...

While I understand your concern (that the computational architecture
should not force signaling behavior) I do not believe that it can be
addressed by limiting the discussion to the CCAMP working group. It is
clear that the PCE working group is responsible for the PCE architecture
and should suggest applicability to specific environments including
multi-domain MPLS-TE and GMPLS. The questions then arise: if the
application of PCE to a specific environment requires additions to the
MPLS-TE or GMPLS signaling protocols:
1. which working group should decide that the applicability of PCE in this
environment is valid?
2. which working group should identify the requirement for these protocol
extensions?
3. which working group should validate the requirements for these protocol
extensions?
4. which working group should develop the protocol extensions?
5. which working group should review the protocol extensions?

*My* answers to these questions are:
1 PCE and CCAMP
2 PCE
3 CCAMP
4 PCE
5 CCAMP

My reasoning is:
- the purpose of PCE is to do this work
- CCAMP cannot (and should not) do everything
- CCAMP must keep "supervision" of protocol extensions

I would like to hear other people's opinion on both issues - that raised
by JP and that raised by Dimitri.

Thanks,
Adrian

----- Original Message ----- 
From: "dimitri papadimitriou" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>; "JP Vasseur" <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, August 12, 2005 7:59 PM
Subject: Re: PCE Requirement in CCAMP