The MPLS WG Archive

[Curtis Villamizar <curtis@fictitious.org>]

In message <0536FC9B908BEC4597EE721BE6A35389025D659E@i2km07-ukbr.domain1.system
host.net>, neil.2.harrison@bt.com writes:
> 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


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


> > -----Original Message-----
> > From: John Drake [mailto:jdrake@calient.net]
> > Sent: 06 March 2003 17:46
> > To: 'curtis@fictitious.org'
> > Cc: 'Yangguang Xu'; Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin;
> > mpls@UU.NET
> > 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:curtis@fictitious.org]
> > > Sent: Thursday, March 06, 2003 7:54 AM
> > > To: John Drake
> > > Cc: 'Yangguang Xu'; Dimitri.Papadimitriou@alcatel.be; Zhi-Wei Lin;
> > > mpls@UU.NET
> > > 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: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.
> > > 
> > > 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
> > > 
> > 
>