The MPLS WG Archive

[Yong Xue <yxue@UU.NET>]

Hi, Here is my 2 cents ..

At 06:14 PM 10/19/00 +0100, darren.freeland@bt.com wrote:
>Hi Bala,
>
>I agree totally with what you said.  I think I perhaps gave the impression
>to Alex and John that I am against an IP-centric control plane.  This is not
>the case - I'm not against any type of control plane just yet.
>
>My first point is that we have to fully understand the requirements of the
>optical layer before we decide upon which protocols to use for it.  My
>second point is as you stated - the peer model is impractical for an
>operator who wants to have a multi-client OTN (whether the control plane is
>IP-centric or not).  I would like to see some more debate on both these
>points, because I'm sure there are many keeping quite who have strong views
>on both.
>

As an ISP owned by an telco operator, I am wearing two hats. I would like
to make sure the next gen OTN will be able to service not only IP clients,
but also other type of clients, such as ATM, PL, Frame Relay, etc. from a
telco
operator's perspective, On the other hand, as an  ISP, I am more concerned
with how
the OTN can be optimized for IP clients. 

I think both overlay model and peer model should be supported. OTN should
be designed
to allow the operator to choose either one of them, or both, depending on the 
service and business model it uses. However considering the complexity and
security
issues associated with the peer model, the overlay model should be
supported first. 
This model works and carrier feel comfortable with it the most. As
technology evolves,
the peer model should find its application and acceptance by the carrier.

For example, as an ISP, we would like to have our routers to control not
only what 
lightpaths to be set up end to end by OTN, but how they should be set as
well (router determines
the explicit routes). Due to the business relation of the ISP with its
parent carrier,
this is a viable model. This is why the peer model should be supported.

In an idea scenario, a policy-based configuration support at the
demarcation point
between the client network and the carrier OTN should allow the carrier to
configure
which port is running overlay model and which one is peer model.

As for which control plane protocol we should use, I  think we should open
to all
the existing protocols  (MPLS/GMPLS, PNNI, SS7, etc.). I think the carrier
should form 
a group and come up with a control plane  protocol requirements and see
which of them
can best serve the requirement. I think we should allow more than one
signaling protocols
to exist. Actually, the recent T1X1 meeting has formed an ad hoc group to
be participated
by most of the US carriers to work on a signaling protocol requirement doc
for ASON. Since
the carriers are the ones that are going to buy the equipment to build
their next gen OTN,
their opinions should be seriously heard.

In my opinion, IP-centric control plane like MPLS-based one sound better
simply because we can
reuse a proven technology at IP layer and it make it easier to implement
the peer model for
the IP clients. This may preclude some type of the client types (ATM, PL,
etc) from working with 
the peer model, but it should work for the MPLS-enabled ATM or FR switches.
Think about the 
future, 90% of the traffic is going to be IP  and the IP clients should be
dominant when we have 
to make a choice one way or the other. The other types of clients can still
be serviced by the 
overlay model though.



/Yong



Yong Xue
Global Network Architecture
UUNET/WorldCom
Ashburn, Virginia
(703)-886-5358
yxue@uu.net