The MPLS WG Archive

[Yakov Rekhter <yakov@cisco.com>]

Darren,

> >>> 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 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 pragmatic?

Yes. And to see why, note that quite a few OXC vendors ship today
proprietory/closed control planes, and service providers buy this
equipment, even despite the fact these control planes have been
developed well prior "to fully asking the question".

At the same time, I have nothing against people working on a PSFGTC
(Perfect Solution For Generations To Come). I've seen such efforts in
the past, and I hope they'll continue unabated in the future.

> >>> 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. 

The above section points to some of the problems associated with the
overlay model, and especially with the overlay model where you have
multiple control planes that have separate, dissimilar control and
operational semantics.  One may call these problems "bias", or one may
just ignore them, but that isn't going to make these problems
disappear.

Yakov.