The MPLS WG Archive

[Yakov Rekhter <yakov@cisco.com>]

Darren,

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

No, it is not "perfect" - it is just pragmatic.

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

> The draft shows a clear bias towards the peer option.  

Perhaps you should re-read the following (Section 8 of the draft):

   Essentially, there are two extremal architectural options for
   deployment of the proposed control plane in an operational context
   consisting of LSRs and OXCs.

    - Overlay Option: One option is to use different instances of the
      control plane in the OTN (OXC) and IP (LSR) domains. In this
      situation, each instance of the control plane will operate
      independent of the other. Interworking (including control
      coordination) between the two domains can be established through
      static configuration or through some other procedures that are
      outside the scope of this document. This partitioned and
      explicitely decoupled deployment option allows maximal
      control isolation between the OTN and IP domains. This scheme is
      conceptually similar to the model in use today, whereby the OTN
      simply provides point-to-point channels between IP network
      elements with very minimal control interaction between the two
      domains.

    - Peer Option: Another option is to use a single instance of the
      control plane that subsumes and spans LSRs and OXCs.

   Other architectural options are also possible which allow various
   degrees of control isolation and control integration between the OXCs
   and LSRs.

   To improve scalability the control plane may use routing hierarchy
   (e.g., routing areas). Hierarchy may be applied in either of the
   situations mentioned above. Furthermore, in the overlay option with
   different control plane instances for OXCs and LSRs, hierarchy could
   be enabled for each control plane instance independent of the other.

   In the deployment option with a single instance of the control plane,
   each routing area may maintain a link state database that contains:
   (1) physical LSPs (fiber links), (2) optical LSPs (optical channel
   trails), and (3) logical LSPs (conventional label switched paths). As
   a general rule, all of these path-oriented connection entities could
   simply be considered as LSPs with different characteristics. The
   origination LSR (the head-end) of each LSP entity may locally decide
   whether to advertise the LSP (with appropriate attributes), so that
   other LSRs could use it as a link for subsequent path computations.

   There are significant tradeoffs to the above deployment options,
   including aspects related to scalability and fault isolation.
   Additional documents to follow may elaborate on some of these
   aspects.

   One of the advantages of the control plane design approach described
   in this memo is that it potentially allows network administrators the
   leeway to make these deployment architectural decisions based on
   their specific objectives, network contexts, and service models.

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

Yet from the IP routing point of view the overlay model has exactly
the same problems, irrespective of whether the overlay is realized
over ATM, or OTN, or X.25, etc... In other words, overlay is an
overlay, irrespective of the underlying technology.

> We (inc other operators) have made our feelings clear on the peer model.  

Yes, indeed, as indicated in the following e-mail from UUNet:

Yong Xue> I think both overlay model and peer model should be supported.  

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

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