RE: ASON reqts

["Varma, Eve L (Eve)" <evarma@lucent.com>]

Hi all,

I concur with Zhi that the document is not yet ready to be a WG document.

Regarding the explanation of requirements, I am still extremely puzzled as
to why the IPO requirements document is not being cited as a source of
explanation for a number of ASON-related items.  It's almost as though it never existed.

Best regards,
Eve

-----Original Message-----
From: Adrian Farrel [mailto:afarrel@movaz.com]
Sent: Monday, May 12, 2003 6:53 PM
To: Stephen Trowbridge; ccamp@ops.ietf.org
Subject: Re: ASON reqts


> John,
> Ahhhh....
> This sounds like a whole new can of worms. The goal therefore does
> seem to be to develop yet another protocol solution, and I think
> we need to be VERY careful before taking this kind of step.

Steve,
As one of the authors this is not my goal.
It may transpire that this is a necessity, but it is not a goal.
I apologise if anything I said gave rise to the false impression you have
garnered.

One of the problems from an IETF-participant viewpoint is/was that the
requirements were not clear to me. If they weren't clear to me this may because
- they were not readily accessible to me within the IETF
- they were not couched in terms and formats with which I am familiar
- I am a dunderhead.

Only with the requirements clearly stated (in a form I can grok) is it possible
for me to decide whether existing solutions are adequate.

So the requirements draft is written and ITU-aware people are asked to comment
on whether this seems to them a fair representation of the requirements coming
out of the ITU.

OK up to this point?

The next step, is the analysis of whether the requirements have already been
met.
A subsequent draft has been written to identify how the signaling requirements
are or are not met by existing protocols :
draft-dimitri-ccamp-gmpls-rsvp-te-ason-00.txt
Where they are already met, the draft simply points out to another draft.
Where they are not met, the draft explains the short-comings and offers
solutions.

This *second* draft I would expect to be the one that causes heart-burn. It is
with the second draft that we can take issue - does it solve the problems? is it
correct when it says other solutions are broken? etc.  But the second draft is
still in an early stage and is not being proposed for WG adoption (although we
would still welcome comments on it).

> Your assertion now seems to be that RFC 3473+3474 does NOT meet the
> ASON requirements. If this is the case:
> - Does G.7713.2 meet the requirements, and we missed something in
>   the translation to RFC 3474? If so, then we need to supercede
>   RFC 3474 with a better translation, not start over.

Cannot answer this without an agreement on the requirements.

> - Do you think that even G.7713.2 does not meet the requirements?

Ditto.

>   If you believe this to be the case, it seems like the obvious
>   first step would be to inform ITU-T - after all, this is where
>   the ASON requirements came from and it makes no sense to start
>   a new protocol without fixing (and aligning) G.7713.2.

It would certainly make sense to take the ASON reqts draft to ITU-T to formally
request that they confirm that it is a full documentation of the requirements. I
don't suppose Kireeti can do this unless the draft is a WG draft.

> If we made a mistake, lets fix it, but lets NOT start proliferating
> ASON extensions take 2; ASON extensions take 3; ...

Depends on the scale of the mistake?
Can we do the analysis step by step and discover what (if anything) needs to be
done?
First step - check we're all in synch on the requirements.

Cheers,
Adrian