[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Thanks Mark.....the voice of reason!  I absolutely agree with you that
whilst there is potential merit in bringing L3/2 together (if we can get a
decent specification for MPLS.....and most here are not convinced on that
one yet) there is no case at all to bring it together with L1/0.  We made
the point way back in the Freeland draft (Nov 2000) that we saw no case for
the peer-model and have been consistently ignored ever since....and it's
kind of ironic to see this realisation now dawning on others, ie the move to
the 'overlay' model'....better late than never I guess. 

regards, Neil

> -----Original Message-----
> From: Mark.Jones@mail.sprint.com [mailto:Mark.Jones@mail.sprint.com]
> Sent: 06 March 2003 15:14
> To: dwfedyk@nortelnetworks.com; gash@att.com
> Cc: ccamp@ops.ietf.org; mpls@UU.NET
> Subject: RE: I-D ACTION:draft-andersson-mpls-g-chng-proc-00.txt
> 
> 
> 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
> 
> 
> 
> 
> 
> 
>