Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt

From: John Drake <[email-masked]>
Date: Wed, 5 Mar 2003 14:28:27 -0800

Snipped...

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 1:39 PM
> To: Zhi-Wei Lin
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 3) you say in this "Note that although the CALL_ID object is optional
> for GMPLS 
>    signaling, this object is mandatory for ASON-compliant networks, 
>    i.e., the Resv message MUST include the CALL_ID object."
>    so if you mandate it's usage at edges, following this an operator
>    that doesn't implement these extensions is not capable to setup an 
>    lsp through an ason network... this is a major problem in case edge
>    devices are lsr's that will be for most of them gmpls compliant
> 

JD:  There is the same issue wrt Generalized UNI

---

From: Zhi-Wei Lin <[email-masked]>
Date: Wed, 05 Mar 2003 21:43:00 -0500

Hi John, Dimitri,

I guess this is another misconception? How an operator will use this, the
operator already knows. This means that if an operator is going to offer
ASON service then they will be expecting their customers to come in with
ASON capable requests. However, if operator is also at the same time
offering GMPLS service, that's fine as well because they will be expecting
to see a GMPLS request.

There is nowhere that says that an operator must only support ASON and
nothing else. What is said is that if an operator is offering ASON service
and not GMPLS, then the request has to come in with an ASON request. I think
this makes sense since the operator has chosen only to support that model.
Alternatively the operator can choose to support both models, or only GMPLS
models.

Hope this explains...

Zhi

---

From: [email-masked]
Date: Thu, 06 Mar 2003 15:34:30 +0100

zhi, i am not sure to understand here, gmpls specifies a
suite of protocols while ason specifies ditto 

"the set of control plane components that are used to manipulate
transport network resources in order to provide the functionality of
setting up, maintaining and releasing connections. The use of components
allows for the separation of call control from connection control and
the separation of routing and signalling."

i don't see indicated "the set of control plane protocol
implementation..."

thus ason can be seen as a control plane model where a set 
of control plane functional mechanisms has been identified, 
and gmpls can be used to implement them, this has been clearly 
identified in the gmpls architecture i-d:

"the architecture presented in this document covers the main building
blocks needed to build a consistent control plane for multiple
switching layers. It does not restrict the way that these layers
work together. Different models can be applied: e.g. overlay,
augmented or integrated."

taking a look at your below e-mail, you have merged this
model with its implementation (i.e. you assimilate ason 
with the set of extensions defined in G.7713.2) and infer 
that this model can only be implemented with these itu
extensions but where have you seen such a restriction
indicated or mentioned in one of the ietf gmpls documents ?

therefore the point that we have reached is much more 
complex than you seem to indicate we will be confronted
in a very short term future to itu extensions for ason 
model and gmpls extensions for ason model (that supports
full call/connection sep.) and i am not sure this is a 
satisfactory outcome for the user community as other 
seems to indicate as well

thanks,
- dimitri.

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