The MPLS WG Archive

[neil.2.harrison@bt.com]

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