Re: ASON RSVP-TE draft to WG doc

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

Steve,
Thanks for a considered and rational email.

Can I comment on a couple of points?

> No.
>
> Some rationale (very high level):
> It seems premature, and it is not a good idea to have parallel track
> documents in ITU-T and IETF to do the same thing.
>
> In terms of whether it is in Scope, ASON is inherently beyond IETF
> scope. It applies to networks where the transport (data) plane is
> not necessarily IP. It applies to networks where addresses are not
> necessarily IP addresses. It applies to networks where demarcation
> and separation are needed in a manner that is not part of how all-IP
> networks are built. The requirements inherently come from, or belong
> to, ITU-T.

Yet, at the same time, it uses an IP-based signling protocol developed by, and still under
development by the IETF. Those things make it in scope. More precisely, it is explicitly
in scope of the CCAMP WG because it is in the charter.
The charter was reviewed and discussed and I certainly didn't see anyone object.

But, I agree with you that the requirements belong to ITU-T. That is why the current
requirements draft is only an attempt to restate the requirements in terms of GMPLS
signaling and in terms and fortmat that are easy for IETF-heads to parse.

> On the other hand, nobody wants to invent a new protocol from scratch
> when there are existing protocols that meet many of the requirements.
> So we end up with an inherently collaborative activity between ITU-T
> and the protocol experts in ccamp to try to design the best way to
> apply or extend the protocol to meet the additional ITU-T requirements.
> Not only has there been a lot of (not always successful) communication
> between the two organizations to do this, but a lot of the same
> individuals have been involved in the work in both places (which has
> been somewhat more successful).

I'm not sure how many individuals have been actively involved in both processes. This is
clearly something from which both bodies would benefit. I know and understand how
individuals can become involved in the IETF process. How can individuals participate in
the ITU-T process?

> What we have existing is ASON requirements and architecture in G.807 and
> G.8080.
> We have in IETF RFC 3471 and 3473 to cover GMPLS signaling (generic and
> RSVP-TE specific).
> We have in ITU-T G.7713 and G.7713.2 to cover ASON signaling (protocol-
> neutral (generic) and RSVP-TE specific, based on RFC 3473).
> We have the codepoints for the ASON extensions from G.7713.2 assigned
> in RFC 3474.
>
> The impression I have from those who promote this new activity are that
> they believe that there are some things WRONG or MISSING from what we
> have so far. While there have been a number of rumors of problems,
> nobody seems to think that they need to write down a crisp characterization
> of those problems.

Well, I can't vouch for whether it is crisp or not, but if you look at Appendix 1 of
draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt you will find...
"Appendix 1: Analysis of RFC 3474 (and RFC 3476) against GMPLS RSVP-TE Signaling
Requirements in support of ASON"
I believe the authors added this appendix in response to the specific request for a clear
statement of the things that they believed were wrong or missing.

Since you're not the only one to suggest to me in the last month that these things aren't
written down, it is clear that the authors did not make the existence of this text clear
enough. Not did the chairs - sorry.

> No new activity should be started until this is done.
> (Note that Kam Lam, Rapporteur of Q.14/15 sent an email to the WG chairs
> on Nov. 19, and to the full list on Nov. 22 requesting specifics - so
> far no response. See http://ops.ietf.org/lists/ccamp/ccamp.2003/msg01089.html )

Well, it is perhaps a little premature to expect a response. As you know, ITU-T liaison is
(or appears to me to be) a fairly formal process. That means that the text has to be
prepared, drafted, circulated, put before the WG, and then submitted.

We are getting there.

> If this is really the motivation, then the right first step is to put
> down what is wrong or missing in black and white into a liaison statement
> to ITU-T so that we can work collaboratively to come up with the best solution.
> It is not the right approach to just start a parallel track activity which
> could result in divergent solutions to ITU-T problems.

I believe it is the concern of the authors of
draft-dimitri-ccamp-gmpls-rsvp-te-ason-01.txt to start the ball rolling in what they
believe will be an inevitable process of collaboration to produce the best solution. From
this perspective, I don't have any problem with the work proceeding within the CCAMP WG.

Being a work item within the WG ensures that all debate is open on this mailing list. It
*does*not* mean that the contents of the existing draft are about to be cast in stone, nor
that the draft won't ultimately be thrown away.

Cheers,
Adrian