The MPLS WG Archive

[darren.freeland@bt.com]

Yakov,

>>> Putting aside this questionable "okay, here is the answers - now what
was
>>> the question" type approach, I have another big problem with
>>> draft-awduche-mpls-te-optical-02.txt.  Lets pretend that we HAVE
actually
>>> fully considered operators requirements, and the major consensus among
>>> operators is that the reuse of IP protocols is perfect for OTN.  
>
> No, it is not "perfect" - it is just pragmatic.

So you consider coming up with the answers prior to fully asking the
questions to be prgamatic?

>>> If I'm to
>>> start out on this approach with draft-awduche-mpls-te-optical-02.txt
then
>>> I'm going to be building my OTN for IP only.  
>
> Could you point to any specific text in
draft-awduche-mpls-te-optical-02.txt
> to support this ?

It's implicit from the part of text that has clear bias towards the peer
model (see below).  For reasons that I'm not going into again because
they've been beated out on this list over the last week or so (see a number
of previous mails from myself & Neil Harrison with regards to client/server
relationships).

>>> The draft shows a clear bias towards the peer option.  
>
> Perhaps you should re-read the following (Section 8 of the draft):

And perhaps you should re-read the following (section 6 of the draft):

   Given that that both OXCs and LSRs require control planes, one option
   would be to have two separate, independent, and incompatible control
   planes - one for OXCs, and another for LSRs. To understand the
   drawbacks of this approach, especially in IP-centric optical
   internetworking systems, one need to look no further than the
   experience with IP over ATM, where IP has its own control plane (BGP,
   IS-IS, OSPF), and ATM its own control plane (PNNI) [12]. For some of
   the drawbacks see [1,2].

   Given that the control planes for both OXCs and LSRs have relatively
   similar requirements, an alternative approach is to develop a
   coherent control plane technology that can be used for LSRs and for
   OXCs. Such a uniform control plane will eliminate the administrative
   complexity of managing hybrid optical internetworking systems with
   separate, dissimilar control and operational semantics.
   Specializations may be introduced in the control plane, as necessary,
   to account for inherent peculiarities of the underlying technologies
   and networking contexts.

   All of the above observations suggest, therefore, that the MPLS
   Traffic Engineering control plane (with some minor extensions) would
   be very suitable as the control plane for OXCs. An OXC that uses the
   MPLS traffic engineering control plane would effectively become an IP
   addressable device. Thus, this proposition also solves the problem of
   addressing for OXCs. 

>>> As far as I (as an operator with multiple clients) am concerned, it's a
no-go
>>> option for my OTN.  So if I'm to pretend that we have fully considered
>>> operators OTN requirements and came to a consensus on the reuse of IP
>>> control protocols, then I have to insist that vendors who want my money
>>> develop the overlay model first.
>
> That would be fine.

Thank you.

Darren.
 
> -----Original Message-----
> From: Yakov Rekhter [mailto:yakov@cisco.com]
> Sent: 26 October 2000 03:51
> To: Kireeti Kompella
> Cc: mpls@UU.NET; rbonica@mci.net
> Subject: Re: Two orthogonal issue 
> 
> 
> Kireeti,
> 
> [clipped...]
> 
> > One thing that has come out of this debate is that carriers are
> > thinking more deeply about requirements, which is a welcome step
> > forward.  At the same time, several deep-rooted biases are being
> > exposed, and I'll be the first to admit my bias towards using
> > MPLS/GMPLS for the control plane.  
> 
> There are fairly pragmatic reasons for using MPLS/GMPLS for
> the control plane - for more on this folks may read
> draft-awduche-mpls-te-optical-02.txt.
> 
> Yakov.
> 
> --------------------------------------------
> > Disclaimer                               
> >                                          
> > "The information and statements in this  
> > email are supplied and made in good faith
> > and without prejudice.  They do not
> > represent BT's only or final view or
> > position and are subject to any change
> > that BT may wish to make (including a
> > complete reversal).  BT will not be liable
> > for any action you take or not take based
> > upon the contents of this email". 
> --------------------------------------------