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

From: John Drake <[email-masked]>
Date: Wed, 5 Mar 2003 16:09:41 -0800

> -----Original Message-----
> From: Yangguang Xu [mailto:[email-masked]]
> Sent: Wednesday, March 05, 2003 2:55 PM
> To: [email-masked]; Zhi-Wei Lin
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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.

JD:  Oh really?  Where did you read that limitation on the scope of GMPLS?

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

JD:  How is this prevented?

> (Indeed, can the incoming edge send 
> directly to the egress
> edge if it decides only setting up any connection? )

JD:  The technical term for this is Notify.  (Presumably 'any connection'
is a typo for 'a call'?)
 
> -- 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.

JD:  How is this prevented?
 
> -- 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.

JD:  And the right way to do this is the 'Session Name' attribute of
the SESSION_ATTRIBUTE Object, as Dimitri mentioned

> 
> Regards,
> 
> Yangguang
> 
> 
> > 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
> >
>

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Mar 2003 10:53:46 -0500

> JD:  Oh really?  Where did you read that limitation on the scope of GMPLS?

WG charter.
   
   The CCAMP working group coordinates the work within the IETF
   defining a common control plane and a separate common measurement
   plane for ISP and SP core tunneling technologies.

and 

   - Using input from the TE working group, ensure that the signalling
     and measurement protocols provide both the information and the
     control functions adequate to support the traffic provisioning
     and engineering operations of service providers.

GMPLS is for "core tunneling technologies" and requirements are to
come from the TE-WG.

GMPLS is not intended for end to end connections according to the WG
charter.

ASON or any end to end connection oriented technology is not accepted
by the IESG or IETF as a whole as a requirement and therefore there is
no WG to work on ASON requirements.

The closest thing to ASON is PWE3 which is definitely not ASON.

Perhaps the best thing would be for ASON to be considered in a
requirements WG (like IPO, but separate from IPO) and reviewed, not
rubber stamped.  This would be consistent with the current process
which is for an internet-draft to be reviewed by a WG, the IESG, then
the IETF last call and IESG/IAB decision.  There have been requests
for requirements in the past that were far enough outside of the IETF
mainstream to warent a WG to defined the requirements.

Curtis

---

From: [email-masked]
Date: Thu, 06 Mar 2003 18:45:10 +0100

curtis,

> GMPLS is for "core tunneling technologies" and requirements are to

the charter says 
"Define signalling protocols and measurement protocols such that 
they support multiple physical path and tunnel technologies"
 
> GMPLS is not intended for end to end connections according to the WG

please indicate in the charter where this has been said (i don't
see this, but may be i missed it) ? of course today the scope is 
limited to tackle single carrier control plane aspects (and we
are also waiting for tewg guidelines in order to move a step 
beyond) 
 
> no WG to work on ASON requirements.

well here the charter says:

"- Define signalling protocols and measurement protocols such that they
support multiple physical path and tunnel technologies (e.g. O-O and
O-E-O optical switches, ATM and Frame Relay switches, MPLS, GRE) using
input from technology-specific working groups such as MPLS, IPO, etc"

if "optical" switching techno's such as sdh and oth are not 
connection oriented technologies then you should tell me your 
definition of connection oriented technology ? 

also nothing has been said that we want to work on "ASON
requirements" but just give an ietf implementation answer

> mainstream to warent a WG to defined the requirements.

in my view the best that can be done is to "analyze" the ason 
model at the ccamp and deliver our ietf gmpls implementation 
answer, clearly it will be to the user community to tell us
if this answer is satisfactory or not 

also, i am not sure we have to completely re-evaluate and 
re-discuss the work that has been accomplished at q12/sg15 
(even if i strongly believe in some kind of phasing here as 
also mentioned here above) note that q12 himself delivers
updates on ason work (since an outcome is always perfectible)

imho in between do everything and let everything done by others
(and just assign code-points) there is more than certainly a 
consensus that we can find here
 
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

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Mar 2003 13:27:41 -0500

In message <[email-masked]>, [email-masked] wri
> requirements" but just give an ietf implementation answer

None of the technologies above require end-2-end GMPLS signaling.
Tunneling ATM and FR is fine.  Operating GMPLS over ATM and FR is
fine.

> consensus that we can find here

ASON has not been accepted as a set of requirements for GMPLS
therefore work on implementing it should not be undertaken.

Curtis

---

From: Stephen Trowbridge <[email-masked]>
Date: Thu, 06 Mar 2003 12:14:04 -0700

Dimitri,

snip
> consensus that we can find here
Absolutely. And the way we work together and find a consensus is
to get IETF to pay attention to the liaison statements early on and
to respond. Then we all know from the start what gets done inside,
what gets done outside, and what gets done through ongoing collaboration.
Regards,
Steve