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

From: [email-masked]
Date: Thu, 6 Mar 2003 20:50:27 -0000

Curtis,

I am not sure this end-end vs edge-edge distinction is really that
meaningful anymore wrt current IETF activities.  I understand the IETF view
of end-end with IP and just with IP......that is fine/correct from this
perspective.  But if you can accept (please try) that we operators have
several layered networks to worry about besides IP then end-end is simply
between the trail termination points of whatever layer network we are
dealing with.  So, for example, if I have a customer wanting an E1
connection (over which he can send anything he likes) and this is
transported over SDH, there will be a E1 trail, a lower VC12 trail and a
(possible sequence of tandemed/disjoint) even lower VC4 trails...and each of
these trails are in networks in their own right that have an end-end context
in their own right, and they are not congruent wrt to their end points.
These sorts of services and client/server network relationships won't go
away and therefore we need to provide for them....so any solutions proposed
at L1/0 must deal with them, else they are not generic solutions.

They also exist in GMPLS *if* it can be applied to arbitrary clients as some
are suggesting, quite reasonably IMO, that it can (see Note).  However, I
sense from your comments that you regard such an application to be outside
the scope of IETF/GMPLS.
Note - Extract of Mail from Gert Grammel 06 March 2003 16:17:
"please don't forget that due to the 'Generalization' of GMPLS you are free
to do
the split at any application level you wish." 

I also see you brought up PWE3 which does deal with arbitrary clients (and
what does end-end mean here?).  And this is now deemed in-scope I guess?

Seems very confusing to me (and I think others, eg Note above) to work out
what is in/out of scope.  Maybe the easiest thing would be to simply state
that IETF has now extended its remit to cover all layer network
technologies.....since this seems nothing more than a reflection of what is
happening....but if doing so then IETF cannot claim to have generic
solutions unless it caters for the case noted above, ie arbitrary clients of
L1/0, as the vast majority of operators will require this.

regards, Neil

> -----Original Message-----
> From: John Drake [mailto:[email-masked]]
> Sent: 06 March 2003 17:46
> To: [email-masked]'
> Cc: 'Yangguang Xu'; [email-masked]; Zhi-Wei Lin;
> [email-masked]
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> 
> 
> Curtis,
> 
> Oops, sorry.  I was reading the statement as saying that 
> GMPLS could not be
> used for inter-AS (or inter-domain in ASON terminology).
> 
> Thanks,
> 
> John
> 
> > -----Original Message-----
> > From: Curtis Villamizar [mailto:[email-masked]]
> > Sent: Thursday, March 06, 2003 7:54 AM
> > To: John Drake
> > Cc: 'Yangguang Xu'; [email-masked]; Zhi-Wei Lin;
> > [email-masked]
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt 
> > 
> > 
> > 
> > In message <9D42C6E086250248810DCADA39CE7EFC9722BB@nimbus>, 
> > John Drake writes:
> > > 
> > > 
> > > > -----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?
> > 
> > 
> > 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: Curtis Villamizar <[email-masked]>
Date: Thu, 06 Mar 2003 16:16:41 -0500

In message <[email-masked]
> L1/0, as the vast majority of operators will require this.

Neil,

A well thought out and well articulated response.  Thanks.

A major difference between ASON and the work that the IETF has choosen
to undertake is that there is no external party signaling.  In PWE3
means to provide various L2 tunneling over MPLS/GMPLS are provided.
In your example, with the work the IETF is doing the customer can have
their E1 but it is not signaled.  Or the OC12c trunk can be carried
over MPLS/GMPLS, but again, it is not signaled by the customer.  There
is no UNI for PWE3 or equivalent in GMPLS.

A simple way to accomplish the same thing would be giving the customer
MPLS adjacency but filtering requests (no change in protocols) and
requiring that the first hop in the ERO is one loose hop the exits the
network.  No change at all would be required to protocols, just
filterin of the incoming PATH messages (an implementation choice to
provide such a feature).  This is the same idea behind
draft-swallow-gmpls-overlay-00.txt where the ERO is entirely omitted
and no RRO is sent in response.  This is just a step further hiding
the network internals.

Simple and works vs grandeous.  The IETF usually favors simple.

Curtis