The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2000-Oct> msg00504



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Two orthogonal issue

  • From: darren.freeland@bt.com
  • Date: Thu, 26 Oct 2000 15:17:11 +0100
  • Cc: mpls@UU.NET, alan.mcguire@bt.com, andy.bd.reid@bt.com

Yakov,

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

I have read the draft.  Twice.  As far as I can see, the only real
justification given for using MPLS/GMPLS for optical control is the reuse of
existing protocols.  Cool, I think we all agree that we don't want to
reinvent the wheel.  Why not PNNI then?  Why do you say that IP protocols
should be used for the control plane facets?  Again, note that I'm not
advocating any particular approach just yet - I am saying that the
requirements of the OTN (or any other network in the case of GMPLS) should
be fully considered in the first place.  The choice (and extensions) of
control plane protocols should then be made to fit requirements.

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.  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.  The draft shows a clear bias
towards the peer option.  I'm not happy with that.  What's the justification
given for using this model over the overlay option? **To avoid problems
encountered with IP over ATM** ...  sorry, wrong answer.  OTN is not ATM.
We (inc other operators) have made our feelings clear on the peer model.  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.

Regards,
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". 
--------------------------------------------