The MPLS WG Archive

[Alex Zinin <azinin@cisco.com>]

darren,


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

Again, it does not have to (in general), but it can be congruent.
I think this is where we disagree.

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

You said:

> I assume then that you now also acknowledge the single control plane
> 'Peer'
> model as being impractical?

I.e., you sounded like the peer model is impractical at all.
I cannot agree with this, of course.


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

Don't want to expand the discussion in this direction, but I believe
we do have framework documents. I simple search for IDs would help,
I guess.

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

Cool.

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

OK, so why don't you just use the overlay model?

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

Do you mean that the overlay model will not be able to support
multiple clients?

Alex.