Re: PCE Requirement in CCAMP

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

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