RE: Moving right along ...

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Maarten,

> ASON is layer network based, GMPLS is not

Sorry, but you misunderstood how GMPLS works for SDH/SONET.

GMPLS supports *all* approaches that you described: "layer network based"
and/or "hidden set up of a STS-1 or VC-4 trail supporting an additional
VT/LOVC link or extending an existing VT/LOVC link".

The difference between these two approaches is a policy matter and should be
independent of the protocols. That's what we are doing (made) with GMPLS: we
are developing a toolbox without specifying (forcing) the policies.

That's up to the manufacturer to decide which policies he will implement
(e.g. both) and to the operator to decide which policies he wants to use.
Policies can even be dynamic and depends on customers. You can even use the
COPS model to deal with these policies.

To be more clear, at each switch you could have different policies, at some
places the call could fails (referring here to you example), at some places
the call could trigger a "hidden" VC-4. GMPLS doesn't specifies that. An
operator could operate its network in a pure layer network based approach,
or using only the other approach or using a mix.

If you mean that ASON "hardcoded" the policies by limiting the architecture
and the protocols to the example you gave (layer network based), that's a
*serious* limitation of ASON (and by the way totally unjustified). Clearly
from that perspective ASON is a subset of GMPLS. Is it the case ?

Kind regards,

Eric

-----Original Message-----
From: Maarten Vissers [mailto:mvissers@lucent.com]
Sent: Thursday, October 25, 2001 7:04 AM
To: Sudheer Dharanikota
Cc: ccamp@ops.ietf.org
Subject: Re: Moving right along ...


Sudheer,

Another issue is ...

	- ASON is layer network based, GMPLS is not

i.e. a request for a connection within ASON is treated within the boundaries
of
one layer network (e.g. within the boundaries of a VT1.5/VC-11 layer
network, or
within the boundaries of a STS-3c/VC-4 layer network). A VT1.5/VC-11
connection
request is processed within the VT1.5/VC-11 layer network, using existing
VT1.5/VC-11 links (GMPLS: link bundles). If there is not enough capacity  in
the
VT1.5/VC-11 links to support the request, the call fails. There is no
"hidden"
set up of a STS-1 or VC-4 trail supporting an additional VT/LOVC link or
extending an existing VT/LOVC link. The set up of an additional STS-1 or
VC-4
trail is supported within the scope of network planning and/or network
engineering. This is separated from the connection set up.

Regards,

Maarten

Sudheer Dharanikota wrote:
> 
> Hi Maarten:
> 
> Maarten Vissers wrote:
> 
> > Sudheer,
> >
> > At the moment I am unable to briefly summarize the differences between
GMPLS and
> > ASON. I was working from the perception that GMPLS could be one of the
protocols
> > supporting ASON. The technical comments I made during the last 10 months
were
> > based on this perception. Also the last comment describing the concept
of serial
> > compound link had this basis. Reading Yanhe's reply I had the impression
that
> > GMPLS is able to support serial compound links, but reading Eric's reply
I got
> > the opposite impression. Furthermore being very surprised by Eric's
reaction on
> > a pure technical issue, I composed a few challenging words to attrack
more
> > people to participate in the  discussion... :-)
> 
> I see one of the issue here being ...
> 
>     - Does GMPLS support serial compound links?
> 
> Let us enumerate few more questions and move the discussion to a technical
> level again, we need participation especially from the folks who are
involved
> in ASON architecture work.
> 
> >
> > Being impressed by the few hundred people attending the last ccamp
sessions in
> > London, I am surprised by the low percentage of those people being
actively
> > contributing to the correspondence. It can't be the case that only a
handful of
> > people have an opinion on these matters... and I believe the discussions
would
> > stay technical if more people express their opinion... there would not
be a
> > yes/no game between just a few people.
> >
> 
> I thought this is how most of the standards meetings work. 5 % work, 95 %
> try to gather industry intelligence ( :-) ) either by attending IETF or by
following
> 
> the mailing list.
> 
> >
> > With G.8080 (ex. G.ason) and G.7713 (ex. G.dcm) available it will be
possible to
> > start an evaluation of GMPLS as a specific protocol for ASON. As
indicated in a
> > previous email from Steve Trowbridge, ITU-T will make those ASON
documents
> > available to IETF so we can jointly work this evaluation.
> >
> 
> Most of these documents are available on the t1x1 site. But what we need
here is
> the "delta" that is missing between ASON architecture and the view of
GMPLS
> architecture. Can you help us with this? We may start with a short list...
> 
> >
> > The approval of the current ASON recommendations is just a first step
within the
> > larger ASON task. Work is started on other elements of ASON (G.rtg
(routing),
> > G.lm (link management) and pnni based specific protocol as an
implementation of
> > the protocol neutral specification in G.7713)),  discussions are started
> > identifying further ASON elements, and work to extend G.8080 is planned
to start
> > after this SG15 meeting.
> >
> 
> Obviously GMPLS is a potential candidate to solve the ASON issues. It may
be
> ahead of its time as far as ITU and ANSI are concerned. So let us ammend
or
> modify it to the ITU view on the transport control plane.
> 
> Regards,
> 
> sudheer
> 
> >
> > Up to so far... {time to shut down my computer and go to the concert
hall in
> > Geneva... time to relax after a week and a half of hectic work over
here...}
> >
> > Regards,
> >
> > Maarten
> >
> > Sudheer Dharanikota wrote:
> > >
> > > Hi Marteen:
> > >
> > > Can you briefly summarize the differences you see between
> > > GMPLS architecture and ASON architecture? This has been
> > > asked by many of the folks at IETF.
> > >
> > > Regards,
> > >
> > > sudheer
> > >
> > > PS: I thought these mails were about label format and suddenly
> > > this is turning into an ITU versus IETF discussion :-(