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