Re: PCE Requirement in CCAMP

["Adrian Farrel" <adrian@olddog.co.uk>]

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" <dpapadimitriou@psg.com>
To: "Adrian Farrel" <adrian@olddog.co.uk>
Cc: <dimitri.papadimitriou@alcatel.be>; "JP Vasseur" <jvasseur@cisco.com>;
<ccamp@ops.ietf.org>; <pce@ietf.org>
Sent: Friday, August 12, 2005 7:59 PM
Subject: Re: PCE Requirement in CCAMP


> 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:
>
> > Hi Dimitri,
> >
> >
> >>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."
> >
> >
> > 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.
> >
> >
> >>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)
> >
> >
> > 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
> >
> >
> >
> >>>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)
> >>>
> >>>
> >>>.
> >>>
> >>
> >>
> >>
> >
> >
> >
> > .
> >
>
>
>