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

[neil.2.harrison@bt.com]

Gert....its not a nice feature if you don't want to use the forced
functional component set.

Ignoring the commercial vertical (client/server) and horizontal (same layer
partitioning) requirements for functional decoupling, there are certain
behaviours an operator may wish to use at L1/0 that are different to those
the operator may wish to use in a L3/2 network.  Operators may want the
freedom to choose what they consider (whether others agree with them or not)
what they perceive as best-of-breed components.  For example, why should an
operator be forced to use v4 addressing for the user-plane access points at
L1/0?  Why should they be forced to use RSVP-TE signalling if they believe
pnni signalling is better?  Why should they be forced to run a routing
protocol at L1/0 (they may want discovery aspects however and the ability to
hold a routing cache) when they need access to centralised records (eg duct
records), and moreover they want their management system to retain
absolute/overriding control?  It's not clear to me operators have such
degrees of freedom here.

regards, Neil

> -----Original Message-----
> From: Gert Grammel [mailto:Gert.Grammel@alcatel.de]
> Sent: 06 March 2003 16:17
> To: Mark.Jones@mail.sprint.com
> Cc: dwfedyk@nortelnetworks.com; gash@att.com; ccamp@ops.ietf.org;
> mpls@UU.NET
> Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> Mark,
> 
> please don't forget that due to the 'Generalization' of GMPLS 
> you are free to do
> the split at any application level you wish. This was always 
> the advantage of
> the GMPLS approach compared to the ITU-T model where 
> initially each layer had
> its own control plane. So the fact that in theory you could 
> use a single control
> plane for all your network means also that you are able to 
> stop where you want.
> Nice feature isn't it?
> 
> Regards
> 
> Gert
> 
> Mark.Jones@mail.sprint.com wrote:
> 
> > I agree with the separation of GMPLS into the two 
> applications.  There
> > does not appear to be any significant move to collapse the 
> management or
> > signaling for L3/2 and L1/0 at this time, given the different models
> > that apply for them and the infrastructures in our 
> companies that manage
> > them.  The plan for addressing the two applications need not be the
> > same.
> >
> > The L3/2 application is near and dear to the heart of the IETF.  The
> > L1/0 application is of interest to those who wish to collapse the
> > management into a single layer.  In my opinion, the IETF might also
> > address this approach, given the IETF participants are the ones in
> > support of this collapsed management or at least common protocol
> > solution for what is today two signaling layers.  However, as stated
> > before, the collapse approach is not realistic today for a
> > multi-service, multi-protocol network.
> >
> > On the other hand, the L1/0 application requirements and models have
> > been defined and are best understood at the ITU-T.  Ideally, the
> > protocol expertise at the IETF would be applied to the 
> ITU-T model and
> > requirements to address the L1/0 application, but attempts 
> to do that
> > have been met with great resistance in the past.  Perhaps that was a
> > result of the fact that GMPLS implementations were not separated out
> > into the two different applications.  However, I don't think it is
> > realistic to expect the IETF experts to be motivated to 
> understand the
> > ITU-T models and requirements, given the application is 
> outside of their
> > primary area of interest.  That said, I believe the IETF 
> should reach an
> > agreement on how to work with outside groups that develop "major
> > extensions" to the protocol.
> >
> > Mark Loyd Jones
> > Optical Transport and Networking
> > Sprint - Wireline Technology Development
> > 913-794-2139
> >
> >
> > -----Original Message-----
> > From: dwfedyk [mailto:dwfedyk@nortelnetworks.com]
> > Sent: Thursday, March 06, 2003 7:49 AM
> > To: gash
> > Cc: mpls; ccamp
> > Subject: Re: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> >
> > Along the lines of Jerry's comments.
> >
> > When we put together GMPLS the first drafts were under specified
> > intentionally to capture the essence of GMPLS. We put aside many
> > arguments saying lets specify at a high level and fill in 
> the details
> > later. The discussions on this thread are in two major veins one
> > attempting to fill the details and the other containing and 
> controlling
> > the changes. GMPLS needs to be specified more accurately and in my
> > opinion it needs to be decomposed to a more layered 
> approach.  I think
> > if we applied GMPLS at at some layers (L3/2), (L1/L0) for example,
> > independently but self similar it would offer a mechanism to move
> > forward where some legacy systems could be specified to be GMPLS
> > friendly. For example signaling for Layer 3/2 can be 
> tunneled through
> > the a lower layer. We already have some work in this direction.
> >  Similarly traffic engineering information for L1/L0 in a 
> TE database
> >  would need different  attributes than a the TE database at L3/2. I
> > don't think you want to burden a L3/L2 system with these 
> attributes in
> > an overlay model. The expertise for these layer is not all 
> contained in
> > the IETF. I think we should put a plan forward to make this happen
> > within the IETF process. After this was accomplished  I think some
> > people are thinking of collapsing layers even more but the logical
> > partitioning of layers may help keep the protocols and databases
> > simpler.   Right now were are treating GMPLS like a big 
> bowl of jelly
> > when it should look more like a layer cake.
> >
> > Regards,
> > Don
> 
> --
> Alcatel Optical Network Division    Gert Grammel
> Network Strategy                    phone: +49 711 821 47368
> Lorenzstrasse 10                    fax: +49 711 821 43169
> D-70435 Stuttgart                   mailto:Gert.Grammel@alcatel.de
> 
> 
> 
>