[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Moving right along ...
Hi Eric,
Let's not say which one is sub-set of which other one. As I mentioned,
ASON and GMPLS (or ASON and PNNI, but from what I understand IETF
doesn't do PNNI so this issue is not discussed here) are complementary.
Let's treat it that way and move forward by trying to align the two so
that the industry will benefit (my little rambling again).
However, there are still some issues of GMPLS technology specific that
still needs to be resolved. Those are not ASON issues, since ASON treats
these as generic "labels". From what I understand several people are
still discussing this (I use "discussing" broadly...it sounds
better)...I think you know my position and several people's position on
this...
Zhi
Mannie, Eric wrote:
> 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 :-(
>>>>
>