The MPLS WG Archive

[darren.freeland@bt.com]

Alex,

> If you establish an LSP across your
> optical network, it will look like a link to your client.

Indeed - so we agree that the link could consist of a number of trails in
the server layer.  Which means that addressing cannot be congruent across
client and server layers.  Which means that your single control plane 'Peer'
model is impractical in a multi-client environment.  I don't see how you can
agree on the 1st part but not on the 2nd.  Maybe I'm missing something, if
so please explain.

>>> Okay, using a single 'best of breed' routing
>>> protocol
>
> Wrong assumption (OSPF+ISIS).
>>> and a single 'best of breed' signalling protocol
>
> Wrong assumption (RSVP-TE + CR-LDP).

This is something that I haven't understood since I began following IETF
work.  Right from the outset, it has been assumed that these particular IP
routing and signalling protocols will be used for the optical layer control
plane.  As far as I can see, these assumptions were made before any
consideration was given to the requirements of the optical layer.  If I am
wrong, then why aren't these requirements documented in an internet draft?
Don't get me wrong, I am not saying that these protocols (with appropriate
extensions of course) are not up to the job - whether they will be or not is
not the point here.  What I am saying is that IETF work on the optical layer
has started out by saying "these are the answers" before having fully asked
the questions.

That apart, I would also question your choice of control plane facets given
that there is no relationship between IP and OTN user planes.  Note that
ITU-T are developing the OTN user plane in G.709.  In which IP packets will
be treated as any other client and carried with a defined frame structure. 

>>> it follows from the above simple concept
>>> that the addresing scheme used by the optical layer
>>> cannot be related to any particular clients (ie not from
>>> the same addressing space in terms of possible trail
>>> connectivity at layer network access points).
>
> Wrong assumption.
> I does not have to be related, but it can.

If an operator wants his optical transport network to be single client, then
yes it can be related.  This would be your 'Peer' model.  As an operator, I
do not want my OTN to be single client.  Therefore I do not want congruent
addressing across my OTN and ANY client layer.  I'm sure I'm not the only
one who holds this view.

>>> Sure this would not be the case if IP was
>>> the only client of the optical layer, but (*reality check*), operators
WILL
>>> still be making most of their revenue from non-IP clients for a long
time to
>>> come, and therefore an optical transport network WILL have to support
>>> multiple clients.
>
> Do you mean there is a contradiction with
> the work currently being done?

Do you mean that the work currently being done supports an OTN that can't
have multiple clients?  As an operator with many clients and not just IP, I
can't support that.

> I would say we should develop the OTN control plane first.

Indeed :)  Wouldn't it be logical to have a defined set of requirements from
which the control could be developed though?  Sure would make life a lot
easier.

Regards,
Darren.

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