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

From: [email-masked]
Date: Wed, 05 Mar 2003 22:39:29 +0100

zhi,

some comments in-line (i hope this will open the discussion
on this):

Zhi-Wei Lin wrote:
> 
> Hi John (also Dimitri),
> 
> Responding to your email and Dimitri's. I did not have a copy of your
> email (apparently I was "delete button" happy last night and just wiped
> all email away)...
> 
> I was just wondering whether you've actually read the documents on the
> ASON extensions. 

1) yep, and this is why i try to open a discussion here

> For instance, your comments about the compatibility
> with GMPLS seems a strange comment. If you look at the ASON extensions,
> you should have noticed that the object-class numbers that was
> requested and assigned are in the range where any RSVP-aware node that
> does not understand the ASON objects would simply forward them. From
> the perspective of the ASON models, the objects are associated with the
> call controller. Call controllers are not pervasive at every location
> within the network. Only call controllers need to understand this. If
> an operator deploys a network with call controllers then that would
> suggest that the nodes that has to perform call controller function
> must therefore have this capability. All other nodes may remain GMPLS
> nodes. From the perspective of the model, the GMPLS nodes that are not-
> ASON extension aware will simply serve as the connection controllers
> and simply forward the ASON objects forward to the call controllers.

three things here:

1) well i am surprised because in both directions there are problems
   - if what's in the current document doesn't do the job for full 
     call/connection separation you will be obliged to have a new
     mechanism
   - if what's in the current document does the job and the message is 
     received by a non-compliant gmpls node you will setup the
connection 
     without prior establishment of the call !

2) you say that call controllers do not need to be co-located to 
     connection controllers but then how using the current mechanism
     you can simultaneously setup the call and connection ?

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

> Your other comment was about the use of the Notify message for the call
> purpose. Again, if you've read the document you would notice that there
> are two call/connection models that need to be supported: one is the
> call with connection, and one is call without connection. My
> understanding is that call with connection is the one ITU wants to
> handle first. As such the document mainly talks about call with
> connection. Using the Notify message, the Notify message cannot set up
> connections. All it can perform by the very nature of the definition of
> the Notify message is to handle a call. This means that the Notify can
> only be used to support call without connection, and a separate
> mechanism is needed for call with connection. So here I see that the
> current method defined for the ASON is actually more flexible and
> covers both cases.

1) the notify mechanism allows for setting a call w/o connections
2) we do not need new object or extension to name a bunch of lsp's 
  (just using session name)
  
> Your other issue about the support for the generic virtual
> concatenation capability. You're right we don't cover this yet. My
> understanding is that the ITU is still working out the technical issues
> of this and the requirements for how things should behave. Once these
> decisions have been made, I'm assuming the next logical step is to ask
> IETF RSVP experts for help and feedback. Hopefully this time around,
> when the request for help comes in, people will not ignore it for 1-2
> years and then simply make lots of noise at the end saying that they
> weren't aware of any of this...

1) let's hope not ;-)
 
> Another items just to make people aware so that we don't get into this
> mess, ITU is currently starting up work to add full
> protection/restoration and crankback capability to the ASON model. This
> work is just starting and at the formulating stage, i.e., getting the
> requirements done. I believe as Kireeti mentioned there were liaisons
> to this effect sent to the CCAMP. One of the inputs that ITU is
> expecting is to have someone bring in the existing work that's been
> done for the restoration/recovery/protection architecture and framework
> work (part of the design team I believe). I think Dimitri was very
> aware of this item, and since Dimitri is one of the active
> contributors/authors for this work, I hope that he will, along with
> other contributors/authors, be submitting this work to ITU to help with
> the specification.

1) this doesn't preclude the other and i am very concerned
   today by the separate specifications we have, the first
   step in a good collaboration is by having a common spec
   on signalling 
 
> Let's try and start working based on a more collaborative mode instead
> of simply making these noise.

1) of course but let me point out something here, i think
   the source noise come when people claim to cover full
   call/connection separation when section 10 in the current
   version of the document suffers from the problem indicated
   here above 
 
> Looking forward to hearing your responses!

1) hope this clarifies a bit 

- dimitri.

> Zhi

-- 
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

---

From: Yangguang Xu <[email-masked]>
Date: Wed, 05 Mar 2003 17:54:34 -0500

Hello,

Some thoughts below, related to both John and Dimitri's response.

We need to differentitate end-to-end operation and edge-to-edge operation first.
GMPLS deals with edge-to-edge connection, G.7713 extends the scope to
end-to-end.

In a specific GMPLS cloud, call can be view as an edge-directly to-edge
operation. It indeed skips the intemediate NEs which are used to only to pass
the call information. The edge NE (with the call capability) decides when to
trigger the connection operation between the edges. Even call/connection can
happen at the same time, they are two different logical steps. 

So, 
-- if a call has no connection, it doesn't allocate resources in the
intermediate nodes. (Indeed, can the incoming edge send directly to the egress
edge if it decides only setting up any connection? ) 
-- connection can only be set up by NEs be able to handle call. So the
connection before call shouldn't happen in this mode of operation. 
-- Where call controller and connection controller locate has nothing to do the
call/connection operation sequence
-- If your NE is not ASON/G.7713 compliant, you can use other mechanisms to
trigger connection. Yet, if your NE is ASON/G.7713 compliant, the NE MUST
support CALL_ID.

Regards,

Yangguang

---

From: Zhi-Wei Lin <[email-masked]>
Date: Wed, 05 Mar 2003 14:56:01 -0500

Hi John (also Dimitri),

ASON extensions. For instance, your comments about the compatibility 

Zhi