The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <3E678926.6A865244@alcatel.be>, Dimitri.Papadimitriou@alcatel.be wri
tes:
> curtis,
> 
> > > > -----Original Message-----
> > > > From: Yangguang Xu [mailto:xuyg@lucent.com]
> > > > Sent: Wednesday, March 05, 2003 2:55 PM
> > > > To: Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin
> > > > Cc: mpls@UU.NET
> > > > 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
> ?
> > 
> > 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.
> 
> 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
> > charter.
> 
> 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) 
>  
> > 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.
> 
> 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

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.

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

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

Curtis