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

[Mark.Jones@mail.sprint.com]

Gert,

I agreed with the intent in generalizing MPLS for the wide range of 
expected applications.  It was my hope that it would succeed.  At this 
point, one might say that the intent has only been partially achieved.  
The problem that has come to light over the past year is the fact that 
there are finer points of the ITU-T model and requirements that are not 
supported by the current IETF GMPLS RFCs and standards track drafts.  
Those aspects are considered significant enough by many carriers and 
their suppliers to warrant further extensions outside of the IETF.  (My 
apologies for not understanding those points well enough to clarify them 
even in examples, but there are many people on this list would could do 
so if they thought it necessary.  To avoid any misunderstand, all should 
know that Sprint does not yet have a company position on this.)  It is 
my hope that we can come up with ways of improving the coordination 
between the IETF and ITU-T.  This thread of discussion is bringing out 
the issues to make that happen.

Regards,

Mark Loyd Jones
Optical Transport and Networking
Sprint - Wireline Technology Development
913-794-2139
 

-----Original Message-----
From: Gert.Grammel [mailto:Gert.Grammel@alcatel.de]
Sent: Thursday, March 06, 2003 10:17 AM
To: Mark.Jones
Cc: dwfedyk; gash; ccamp; mpls
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