Re: ASON reqts

[Dimitri.Papadimitriou@alcatel.be]

stephen, well for me it is entirely clear, we are at a
turning point of the whole story, either gmpls extensions
are backward/forward compatible, or you will end-up in a
way or another with two protocol sets, the issue is "who
gains something in maintaining the current confusing
situation ?" ... the response is clear ... neither the
ietf nor the itu (and unfortunately as a consequence,
both the developer and the user community)

in the note sent by fred baker (early'01), see
http://www.ietf.org/IESG/STATEMENTS/sub_area.txt

it was overwhelmingly clear that the following is the motto:
"For example, optical networking is clearly a next generation
requirement for service providers and for fiber consortia.
However, the obvious next hop router in a general network may
differ from the obvious next hop router in an optical network.
Therefore, the use of optical networking may change the results
that we need to get from routing protocols. It would be better
for us to determine how the routing protocols should model those
networks than for another body to arbitrarily change them or
substitute others."

and the exactly same applies for signalling, if this is still
not clear, i'll explain it as follows, as you want a well-
designed control plane architecture for optical networks, i
want that the corresponding protocol extensions (routing,
signalling, etc.) to be also well-designed and consistent
with the internet protocols, this is my take as an ietf'er.

stepping now in the protocol motivation behind this thread
using the stephen t. detector i would call it a 3.5 motivation:
> Those who think that RFC 3474/G.7713.2 (ITU-T extensions) don't
> meet fully the ASON requirements and are not GMPLS compliant, so
> this draft is a first step not only to fix RFC 3474/G.7713.2
> but also to make them GMPLS compliant

taking one of the main discussion points in the above i-d,
in my view, we should even look at it as follows, what are
the possible methods to achieve call/connection separation
well we have the following possibilities: "rfc3474, extend the
notify message, define a new message" then detail pros and
cons and decide upon wg consensus, which method is the more
appropriate from a technical perspective.

hope this clarifies.

thanks,
- dimitri.

Stephen Shew wrote:
> I have read the requirements draft (and most of this thread) and tend to
> agree with Stephen T. that the problem is not entirely clear.  However,
> for the purpose of dialogue between standards bodies, having a CCAMP WG
> document to liaise is helpful.  In that regard I fine with it
> progressing to a CCAMP WG document.
>
> One major technical comment I have is that the ASON addressing
> requirements aren't fully represented.  For example, "G.8080 defines a
> UNI Transport Resource Addresses for the bearer links at the UNI
> reference point" (from G.7713.2 and G.7713.3).  This is important for
> ASON services.  Also, reference points and call segments are missing.  I
> would hope these can be discussed between CCAMP and SG15.  Hence a
> liaison would be helpful.
>
> -----Original Message-----
> From: Stephen Trowbridge [mailto:sjtrowbridge@lucent.com]
> Sent: Wednesday, May 14, 2003 11:59
> To: John Drake
> Cc: Ash, Gerald R (Jerry), ALABS; Wijnen, Bert (Bert); ccamp@ops.ietf.org
> Subject: Re: ASON reqts
>
>
> John,
> I still think it is better to argue it out now and reach agreement on
> what problem we are trying to solve.
>
> If we accept this as a WG draft without doing this, we seem to be
> accepting that we do have SOME problem to solve, and then arguing later
> on what it was. Regards, Steve
>
> John Drake wrote:
>  >
>  > Regardless of what we do now, I'm sure there will be lots of arguments
>  > later.
>  >
> <snip>
>


--
Papadimitriou Dimitri
E-mail : dimitri.papadimitriou@alcatel.be
Private: http://www.rc.bel.alcatel.be/~papadimd/index.html
E-mail : dpapadimitriou@psg.com
Public : http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491