Subject: FW: Two orthogonal issue

From: "Paul Tasillo" <[email-masked]>
Date: Thu, 26 Oct 2000 10:39:45 -0400

See comments in line...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Thursday, October 26, 2000 10:17 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: Two orthogonal issue

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.

PT>> isn't this the same reason people want to use MPLS on ATM networks? To
solve the ATM scalability problem. From what I understand, IP routing is
scalable and ATM (PNNI) isn't because of the signalling(SVC)/PVC table size.
Perhaps I am missing something here?

-Paul

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:[email-masked]]
Sent: 26 October 2000 03:51
To: Kireeti Kompella
Cc: [email-masked]; [email-masked]
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".
--------------------------------------------

---

From: [email-masked]
Date: Thu, 26 Oct 2000 20:11:25 +0100

<snipped>
> > I'm not happy with that.  What's the justification
	>NH=> The are very good reasons to unite the control-plane apsects
of a CO and CNLS transfer mode at an application interfacing level.  And
although MPLS is only being used in a 'S-PVC' like mode at present to
augment a dominantly CNLS transfer mode, this may not always be the case in
the future, eg if lots of interactive video takes off to use all that BW
that the OTN provides.  However, although this is conjecture, MPLS does
offer the possibility to flexibly respond if needed (and this is where an
IP/ATM harmonisation could never work....essentially due to use of different
addressing).

	MPLS user-plane has still some major availability/QoS issues
unanswered in my opinion...see my last mail to Paul Tassillo on this thread.
Until/unless these are answered, then there will always be a need for L2
VPNs.  Indeed, there will always be a need for L1/L2 VPNs for those
customers who demand them (and in the L1 case, this is wholesale large
managed BW, which has to come from L1 (eg SDH VC4) to be
cost-effective)......and we know there are customers who will always want
these types of service.  This, of course, ignores granfathering other client
types.  So, for operators in this position and who want to serve a wide
market segment, overlay is an essential requirement.  However, I would not
want to stop people doing the peer-model if that suits their
business....indeed its suits me if they do.

	The OTN is agnostic, since it is user-plane PDU-type transparent.
It is also CO/cct-sw.  And if I was being very cynical, I could say that the
only way for router vendors to play in this space is to import their
control-planes.  I have yet to see any evaulation of various addressing,
signalling and routing instances (as independent issues, which they are)
which are based on hard OTN requirements agreed across a large population of
operators.  We are working on this and I know other are too, but the work is
not complete.  So whilst some might favour certain solutions for their peer
model, others may want different solutions for their overlay model.

> 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.  
> 
	NH=> I had a chat to our regulatory department today about
peer/overlay models.  In the UK at least, there are *no* operators who want
to share detailed duct/L1 topology information with other operators......all
UK operators seem to agree with this (for I think quite obvious reasons).
However, if people really want to pursue the peer model then I think they
had better face this inter-operator NNI issue from the outset.....because if
they don't then their model is not going to get them very far, ie they will
have to be content with only being able to run certain services based on it
within a their own single domain....and outside that they will be forced to
go overlay (actually its also partitioning too).  Now consider a global VPN
customer in such a case.....just what sort of model is needed to serve that
customer if you don't have infrastruture to the duct around the globe?
That's why I said those who favour the peer model are fine by me....however,
I'd go and check this with your finance people first.

	Neil