Re: Second incoming communication from the OIF

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

Lyndon,
On another, but related, thread from this communication...

Do you know whether
  The project will result in a design guideline document to assist vendors
  and carriers in optical networks where signaling interworking is required
  between OIF/ITU-T ASON and GMPLS RSVP-TE.
refers to just a subset of the ITU-T ASON or to the whole of it?

For example, there is a basic discrepancy between (for example) G.7713.2 and G.7713.3 in
terms of how Call setup is managed. Since the architecture is intended to be entirely
abstract, the initiating UNI-C cannot know whether the responding UNI-C expects to see
independent or piggy-backed Call setup. This same issue applies at E-NNI reference points.

Although it is possible to conceive of ways of managing this type of problem within
network nodes (for example, at the UNI-N) I should think that a basic requirement before
documenting interworking between OIF/ITU-T ASON and GMPLS RSVP-TE is to document
interworking between OIF and ITU-T ASON.

Thanks,
Adrian
----- Original Message ----- 
From: "Kireeti Kompella" <kireeti@juniper.net>
To: "Ong, Lyndon" <Lyong@Ciena.com>
Cc: "'Brungard, Deborah A, ALABS'" <dbrungard@att.com>; "Adrian Farrel"
<adrian@olddog.co.uk>; <ccamp@ops.ietf.org>
Sent: Wednesday, November 24, 2004 4:34 PM
Subject: RE: Second incoming communication from the OIF


> Hi Lyndon,
>
> On Tue, 23 Nov 2004, Ong, Lyndon wrote:
>
> > I'm reading into your email a concern with the use of "ASON" in the title
> > of the project.  The interworking project is likely to cover ITU-T
> > G.7713.2 as the ASON signaling standard at the UNI and E-NNI, taking into
> > account experiences that members have had implementing and testing
> > protocols.
>
> Our concern is with the project as a whole.  There are several
> deficiencies in G.7713.2 and the OIF UNI; these have been pointed out
> many times by CCAMP, and liaised to the ITU, but we are not aware of
> any significant changes that have been made to the OIF UNI or to
> G.7713.2 to address these problems.  In view of this, it seems
> premature to expend effort attempting to build networks that interwork
> the OIF UNI with GMPLS since future work to fix the OIF UNI is likely
> to have considerable impact on any interworking specifications.  The
> real problem (namely, the ASON signaling requirements as well as a UNI
> and E-NNI) have also been addressed by CCAMP; to continue work on
> G.7713.2, and in fact to use it as the ASON signaling standard at the
> UNI and E-NNI seems to us very shortsighted indeed.
>
> The communication says, "We expect the OIF, ITU-T and IETF will
> continue to work together to minimize or eliminate differences between
> control plane signaling protocols."
>
> Certainly a laudable goal.  Persisting with G.7713.2 and the OIF UNI
> without any willingness to adapt these specifications clashes with
> this goal.  Working together implies converging -- the IETF took a big
> step in this direction by acceding to the ASON signaing requirements
> as stated; it doesn't seem that the ITU-T or OIF are willing to take
> similar steps.
>
> > As you note, GMPLS is being extended to support ASON
> > as well.  It sounds reasonable to comment that some clarification of
> > the project definition may be helpful.
>
> And very importantly, to state the need for more work on this front,
> rather than beginning work on convergence at once.
>
> > This also raises a good point about GMPLS continuing to evolve beyond
> > RFC 3473.  As the work on GMPLS extensions to support ASON functionality
> > continues to develop, this will need to be taken into account.
>
> At what stage?  It seems that instead of converging, the object seems
> to develop a full suite of competing protocols, and only then take the
> GMPLS suite into account.
>
> Kireeti.
> -------
>
>