Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

From: <[email-masked]>
Date: Tue, 10 Mar 2009 12:15:32 -0000

Thanks Sasha,  Good observations...let me try and address them...in-line
please. 

Sasha wrote 10 March 2009 11:34

> Neil,
> Lots of thanks for a prompt and informative response. And I 
> fully agree with you regarding the need for honesty.
> 
> Unfortunately I cannot honestly

NH=> You mean you are not being honest ;-)....I joke of course!

> say that your response 
> addresses my worries even if it does much to help me to 
> understand your approach.
> 
> You've invested substantial effort in explaining (not for the 
> first time!) that IP/MPLS and MPLS-TP will not ever do peer-to-peer
> interworking.

NH=> Sorry....but I do feel very passionate about doing the right
things.  
> 
> There are, however, several reasons to think that de-facto 
> they will. Please consider the following:
> 
> 1. You've provided two examples when, in your opinion, things 
> cannot interwork.
>     Your SDH example (VC4 vs. VC12) is, of course, absolutely valid.

NH=> Yes, this one is intuitively very obvious because the SDH co-cs
mode *forces* the quantisation/assignment of resource (due to the co-cs
mode using regular time-slicing/labelling of resource)....so we can
clearly see that a VC4 cannot 'fit' into a VC12, and things like merging
are simply not possible.  In other modes I do agree it is less easy to
figure out what the differences are.....and more worryingly IMO it is
also much more easy to do the wrong things 'just because it's
possible'....which then have real operational impact later.

>      But I am less than sure regarding your IPv4 vs. IPv6 
> example. E.g., RFC 4038 explains,
>      among other things, how the so-called "mapped IPv4 
> addresses" (i.e. IPv6 addresses
>      in the  reserved block ::FFFF:0:0/96) can be used to 
> allow IPv6 servers to serve native IPv4 clients
>      using the so-called dual stack. While the technique 
> itself is not relevant for this discussion,
>      IMHO it is an indication that "different CI" problems 
> can be overcome if really needed.

NH=> This is a really great example and worth examining a little
further.  The reason we might want to peer interwork IPv4 and IPv6 is
that they are both top-of-stack layer networks...and this is key point.
So each might be carrying the *same* message/file/stream application
adaptation functions, eg UDP/TCP/RTP....and it is these we want to pass
transparently across a peer interworking point.

If one examines a non top-of-stack layer network that does not interface
directly with applications but instead carries a higher level client
network (that itself may or may not be top-of-stack) then one can
quickly figure out that trying to force peer interworking of non
top-of-stack layer networks has no real practical value....it can sure
create a lot of unnecessary work though.

> 
> 2. Nearer to the point, have you looked at 
> draft-martinotti-mpls-tp-interworking-01?
>     To the best of my understanding a substantial part of it 
> is dedicated to exactly the case
>     which you consider non-existing (namely "peer model" of  
> IP/MPLS<-->MPLS-TP
>     interworking). And I believe that Verizon's comment on 
> Requirement 16 of the MPLS-TP
>     requirements draft actually refers to peer interworking 
> between IP/MPLS and MPLS-TP
>     (please take a look at the related email thread on this 
> list) indicating, IMHO, that such
>     scenarios are relevant to network operators and not just 
> to the vendors.
>     (I've added Andy to the CC list just in case I've 
> misinterpreted these comments...).
>      And, of course, inability to differentiate between 
> MPLS-TP and IP/MPLS in the DP facilitates
>      such interworking, be it intentional or not.

NH=> I am also very glad you brought this one up too.  It really upsets
me to see various technology fora like OIF, MEF and MPLSF pushing peer
interworking (ie UNIs/E-NNIs) in what are clearly non top-of stack layer
networks.  Sure I can understand why such fora might push their
favourite technologies like this but I do not think they are serving the
best interests of our industry.  Perhaps only ATM was the only
technology that could have really laid claim to 'challenging'
IP/Internet and the PSTN as a top-of-stack layer network....because it
did have message/file/stream application adaptation functions in its
AALs.  If I look at Optical layer networks, Ethernet or indeed MPLS they
do *not* natively support end-system application adaptation functions
for message/file/stream cases.....this is not to say they can't do so,
but that they currently do not do so.  And when this is the case, then
one does not have to be a genius to go through the analysis to show that
peer interworking makes no sense....you might as well just fully
terminate the (lower) networks and pass across the client (higher) level
network they are carrying (hopefully in a proper client/server manner).

> 
> So, unfortunately, I remain worried... and I'd be happy to 
> hear what other people think about it all.

NH=> I understand why you are worried.  Whilst we have folks pushing
incorrect architectural ideas then we are going to have downstream
problems.  Forcing peer interworking when a non top-of-stack layer
network is indeed not a good idea IMO.....but think it through for
yourself, IMO its obvious why this should be true but I accept this
might not be so obvious for everyone.

BTW - This is not simply just a technical issue....though the technical
arguments stand on their own merit.  There can be legal/regulatory
considerations for operators in some countries.  So whilst those
advocating peer interworking of non top-of-stack layer networks can be
quietly ignored on purely technical grounds, it is very serious issue
for those operators who may be subject to legal/regulatory pressures to
provide such interconnects.  And this is one reason why I take this
topic very seriously. 

regards, Neil
> 
> Regards,
>         Sasha
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, March 10, 2009 12:46 PM
> > To: Alexander Vainshtein; [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]; Alik Shimelmits
> > Subject: RE: Is MPLS-TP a profile of MPLS? (was: Clarifying
> > MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))
> >
> > Thanks Sasha....I am so pleased someone else has latched on
> > to this (but
> > to be fair I do think others have understood what I meant here, eg
> > Adrian F, John D and Malcolm B).  I have tried to clarify a little
> > further below:
> >
> > Sasha wrote 10 March 2009 05:54
> >
> > > I must say that I find Neil's statement below about MPLS-TP
> > > NOT being a profile
> > > of the existing MPLS most worrying.
> >
> > NH=> Please don't.  This should not been seen as a cause 
> for concern.
> > This all comes back to what defines a layer network...and
> > most important
> > here is to simply think of the access points and whether they can
> > communicate with each other (and one can see immediately that the
> > addressing of access points is key here, but it is not the
> > only thing as
> > we also require consistent Characteristic Information (CI)).  Let me
> > give a couple of examples to illustrate what I mean and 
> then I'll come
> > back and deal with MPLS/MPLS-TP.
> >
> > IPv4 and IPv6 are examples of 2 quite different IP cl-ps mode layer
> > networks.  This one is quite obvious, the traffic unit (ie
> > packet) has a
> > different structure (ie the CI is different) and they have different
> > addressing formats.  Quite clearly an IPv4 access point
> > cannot directly
> > communicate with a IPv6 access point.
> >
> > IMPORTANT ASIDE => Both these IP layer networks are what I
> > have started
> > to call 'top-of-stack', and what I mean by this is that they do not
> > normally support higher layer networks but they do support 
> end-system
> > adaptation functions for message/file/stream applications, eg
> > UDP/TCP/RTP.  This issue (ie whether a network is 
> top-of-stack or not)
> > is crucial when we come to consider peer-interworking....the
> > simple rule
> > is 'if not top of stack then we do not need peer-interworking across
> > E-NNIs.'....we would just make unnecessary work/cost for
> > ourselves doing
> > that.  And this is important for MPLS and MPLS-TP cases, as 
> neither of
> > these are top-of-stack networks...ergo they have no need to
> > interwork as
> > peers.
> >
> > Consider now the SDH VC4 and VC12 layer networks.  Here it is very
> > obvious that we cannot connect a VC4 access point to a VC12 access
> > point....the CI is very different.  However, the access 
> points of both
> > the VC4 and VC12 layer networks could have exactly the same 
> addressing
> > format;  they simply exist in a different layer network
> > space.  Moreover
> > they can use the same OOB CP (say GMPLS), though they are quite
> > different instances of the CP.
> >
> > Now consider Ethernet and PBB-TE.  Here the traffic unit looks
> > identical.  They may even use the same addressing format for access
> > points.  However Ethernet is a cl-ps mode layer network and
> > PBB-TE is a
> > co-ps mode layer network, so we clearly cannot interwork 
> them directly
> > as peers (there will be conflicts of the CP and the DP OAM, 
> eg AIS/FDI
> > must never appear in a cl-ps mode network, which is why IEEE
> > threw this
> > out of 802.1ag (though it is still in Y.1731)).
> >
> > What I am trying to show here is that it is very common, and indeed
> > sensible, to want to **re-use** components (like addressing, CP
> > signalling/routing, and even traffic units in the
> > Ethernet/PBB-TE case)
> > in **different layer networks**.  The fact that they don't
> > interwork as
> > peers is also very common...and often we take this for
> > granted and don't
> > even really think about it, eg VC4 and VC12 SDH cases.
> >
> > Let me now come back to MPLS and MPLS-TP.  MPLS is not singular in
> > itself, but it is also not like a normal layer network
> > because it allows
> > both MPLS and IP traffic units to co-exist in the DP and this
> > creates an
> > immediate/obvious problem wrt not having consistent
> > CI...something that
> > MPLS-TP must fix and will fix.  Moreover, the traffic units 
> of an MPLS
> > LSP only have context wrt to the protocol that created them, eg LDP,
> > RSVP-TE and MP-BGP4 can all create MPLS LSPs/traffic units...and it
> > should be intuitively clear that, for example, MPLS traffic
> > units issued
> > from an LDP access point are not 'meaningful' to an RSVP-TE
> > access point
> > (which is why you may have seen me remark in the past that 
> even though
> > the DP traffic unit CI is not consistent in MPLS we ought 
> to at least
> > try and get the DP OAM consistent, because if DP traffic does get
> > misconnected then the sink access point will always process 
> the DP OAM
> > in same/consistent manner and correct;y detect the defect).
> >
> > Now MPLS-TP will remove most of the major CI problems in 
> MPLS, and it
> > will also remove the merging problem.  This has an immediate very
> > profound effect that PWs are not relevant to MPLS-TP.  Indeed all
> > clients will be treated equally.  Further, we will add a 
> PPP-based PID
> > to the DP (assuming we adopt Stewart's draft
> > draft-bryant-pwe3-packet-pw-00.txt) and will will add the 
> GMPLS based
> > logically OOB CP.  We may even add different OAM.  All this 
> means that
> > MPLS-TP will be a different layer network instance to any
> > curent spin of
> > MPLS.  This is just a fact and nothing to get worried/upset about.
> > However, what we should not do is generate FUD with talks of
> > 'bacakwards
> > compatibility' and 'peer interworking' with MPLS as-is....all
> > of this is
> > not necessary...and as I noted above no variety of MPLS is
> > top-of-stack
> > so peer interworking them is a non-issue.  All we are doing
> > with MPLS-TP
> > is re-using existing MPLS (and GMPLS for the CP) components
> > to create a
> > new layer network.
> >
> > Hopefully that helps clear things up a bit.
> >
> > >
> > > My worry has been initially triggered by a string of specific
> > > proposals on this list which,
> > > if accepted, IMHO and FWIW, would mean exactly that. (One
> > > recent example
> > > is the proposal to restrict MPLS-TP to using only
> > > per-interface label state.)
> > >
> > > Neil's message makes this trend explicit (which is good!),
> > > and, IMHO, calls for some action.
> >
> > NH=> The main action we need Sasha is a bit more honesty 
> and to start
> > getting things done architecturally right.  For example, I'd
> > like to see
> > everyone accept that MPLS-TP will not have PWs....it's just a fact
> > guys....look at is as an improvement over MPLS, because that
> > is exactly
> > what it is.
> >
> > I would also like to see:
> >
> > -     the DP OAM look identical to DP traffic....this is such an
> > obvious thing to get right I find it hard to understand those
> > who argue
> > against it.  So if we are going to use
> > draft-bryant-pwe3-packet-pw-00.txt for the new MPLS-TP DP adaptation
> > (though I do struggle to understand why the CW is useful here...GFP
> > ought to be looked at at least for adaptation, and this 
> also has a PID
> > field), then the OAM indicate flag needs to be here....not
> > sitting under
> > the GAL;
> >
> > -     I'd like to keep CP/MP protocols cleanly seperated from the DP
> > traffic and DP OAM.
> >
> > >
> > > I believe that the agreement (worked out by the JWT) to
> > > develop MPLS-TP as the profile of MPLS
> > > (and not as something very else) is the sole justification for:
> > > (a) Sharing protocol numbers between MPLS and MPLS-TP (so
> > > that the two cannot be distinguished in
> > > in the data plane)
> > > (b) Developing MPLS-TP at IETF.
> > >
> > > If the JWT-defined framework is broken, what remains?
> >
> > NH=> I'd suggest we exercise some common sense now.  MPLS is not
> > singular anyway as I have tried here and many times
> > previously to point
> > out.  Since we are not going to interwork them (and we don't
> > now if you
> > think about is, ie we don't interwork LDP and RSVP-TE access points)
> > then this is a moot point IMO.
> >
> > I simply want to try and get MPLS-TP into the best shape that is
> > possible.  And I think we can do that if there is the will 
> to do this.
> > Needs some honesty however.
> >
> > regards, Neil
> > >
> > > Regards,
> > >      Sasha
> > >
> > > ________________________________________
> > > From: [email-masked] [[email-masked]] On
> > > Behalf Of [email-masked] [[email-masked]]
> > > Sent: Monday, March 09, 2009 7:14 PM
> > > To: [email-masked]; [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: Re: [mpls-tp] Clarifying MPLS-TP requirements
> > > forMPLS(-TP)    overMPLS(-TP)
> > >
> > > Thanks Stewart,  please see in-line:
> > >
> > > Stewart Bryant wrote 09 March 2009 15:08
> > > >
> > > > Loa Andersson wrote:
> > > > > Malcolm,
> > > > >
> > > > > Malcolm Betts wrote:
> > > > >> Ben, see in line below - I have snipped some text 
> for clarity:
> > > > > <snipped even more - Loa>
> > > > >
> > > > >>
> > > > >> I think that the requirements draft should indicate that
> > > > all frames,
> > > > >> i.e. client data, OAM, SCC, MCC, etc MUST receive
> > > > identical treatment in
> > > > >> the data plane and therefore MUST use the same header
> > structure.
> > > > >
> > > > > all packets with the same label on top will get the same
> > > treatment,
> > > > > given that the TC field is the same, won't they? Is this
> > > > what you mean
> > > > > by "header structure" or did I miss something
> > > > >
> > > > > /Loa
> > > > >>
> > > > >
> > > > >
> > > >
> > > > There is a bunch of confusion about what happens in 
> MPLS networks.
> > >
> > > NH=> I agree.  And I think one of the most worrying things I
> > > am seen is
> > > to assume that MPLS-TP will somehow just be a profile of
> > what MPLS is
> > > today.  It won't be.  Sure we will re-use many component
> > parts, but we
> > > will also be adding some new ones like a PID field in the
> > DP, probably
> > > new OAM and we will be taking CP/MP functions logically OOB
> > > wrt traffic
> > > DP.
> > >
> > > Of a more general/practical architectural note however is
> > > that MPLS (any
> > > spin) and MPLS-TP are *not* top-of-stack layer networks, and
> > > this means
> > > there in no sense in trying to interwork them as peers.  They will
> > > either carry other non top-of-stack layer networks (so this
> > > one is very
> > > obvious reason as to why peer interworking is not required, ie
> > > MPLS/MPLS-TP terminated either side and only client passed
> > > transparently)  or IP which is the top-of-stack layer network
> > > (and here,
> > > ie in the IP layer, peer interworking is vital).
> > >
> > > So any arguments based on being backwards compatible with
> > > existing MPLS
> > > make little real sense.
> > >
> > > >
> > > > In transport networks - set up statically or via GMPLS only
> > > > the top label
> > > > effects the path (although TC effects the queuing).
> > >
> > > NH=> Strictly speaking Stewart a transport network should be fully
> > > transparent and treat all client symbols equally (which 
> is what all
> > > co-cs mode networks do and it is one reason why they are so
> > > succesful as
> > > transport networks).
> > > >
> > > > There are no standard methods for looking at any other
> > label and in
> > > > any case this is only done in networks where the path is chosen
> > > > by an IGP.
> > > >
> > > > If we always use a PW then the requirement for client data,
> > > OAM, SCC,
> > > > MCC to receive identical treatment in the path to the PE
> > > > occurs because
> > > > the label stack is identical.
> > >
> > > NH=> The stark technical reality is that when we create 
> MPLS-TP (by
> > > doing things differently to LDP MPLS)  then there is no need
> > > for PWs (or
> > > even the CW)...all clients get treated equally, they have to
> > > be else it
> > > won't be transport network.....so every client is a PW if you like
> > > (which kind-of makes the name PW and any distinction
> > inferred by this
> > > quite irrelevant).
> > > >
> > > > The only case where the label stack will be different is
> > when we are
> > > > carrying an LSP OAM in which case the GAL needs to be present.
> > >
> > > NH=> This is both my original and Malcolm's point.  The defect
> > > detection/handling OAM very clearly belongs to the DP and it
> > > should have
> > > an identical (in all respects) header to a normal traffic
> > > unit.  This is
> > > why I said to you Stewart that if you are proposing
> > >
> > 
> http://www.ietf.org/internet-drafts/draft-bryant-pwe3-packet-pw-00.txt
> > > as the DP encaps for MPLS-TP then the OAM indicate function
> > > needs to be
> > > in here, eg as a PPP codepoint say.  I don't see why we
> > need the CW as
> > > its not doing much useful (as adapatation) but if you 
> really want it
> > > then keep it.  But we should ensure that the OAM indicate
> > is here and
> > > not under the GAL, else the DP OAM header will have a
> > different format
> > > to normal DP traffic.
> > >
> > > regards, Neil
> > > >
> > > >
> > > > Stewart
> > > _______________________________________________
> > > mpls-tp mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mpls-tp
> > >
> >
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 10 Mar 2009 22:26:40 +0200

Neil,

Thank you again for a prompt response. But allow me to point to yet another potential counter-example:

Neither FR nor ATM have ever been "top of the stack" protocol.
Nevertheless, AFAIK, FRF.8 (which defines peer interworking between FR and ATM) has been not just standardized (by the then FR Forum) but also deployed in operational networks.

Doesn't this fact contradict your key statement? Or did I miss something?

Regards,

     Sasha

________________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, March 10, 2009 2:15 PM
To: Alexander Vainshtein
Cc: [email-masked]; Alik Shimelmits; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

regards, Neil

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 10 Mar 2009 17:13:53 -0400

Dear Sasha, Neil and All,
I hope that I can clarify situation regarding requirement #16 as proposed by
Verizon's team. Andy have explained that "non-homogeneous domains" refers
not to interworking between MPLS-TP and IP/MPLS domains but interworking of
CP and MP across homogeneous DP based on MPLS-TP (I wish I got it right!).
The picture that I've carried from our exchange is that some MPLS-TP domains
might use GMPLS signalling while others will be NMS-provisioned. Additional
requirement - ability to provision MPLS-TP path across such non-homogeneous
(in provisioning sense) domains.

Regards,
Greg

[snip]
> misinterpreted these comments...).
[snip]

---

From: Per Carlson <[email-masked]>
Date: Tue, 10 Mar 2009 22:20:47 +0100

Hi Sasha.

>> hear what other people think about it all.

Worried might be a to strong word, but I'm at least a bit confused
about the direction of MPLS-TP regards to IP/MPLS.

During the MPLS & Ethernet congress in Paris lasth month, at least one
presenter showed slides where MPLS-TP domains where interconnected by
a IP/MPLS domain. That raised the question how a MPLS-TP LSP, with
need of strong OAM, could be delivered over a less (OAM) capable
network. Wouldn't that break the whole picture? If I have interpret
your arguments correctly Neil, my question seams valid.

The "answer" on the question raises another question: Are a service
provider implementing MPLS-TP supposed to build *another* MPLS network
alongside any existing IP/MPLS network? Isn't reducing the number of
diverse networks (e.g. SDH/SONET and IP/MPLS) one of the success
factors today (reducing CapEx and OpEx)? How would running two
packet-oriented MPLS-based networks in parallel be a good thing? Or
are the traditional LSR's in a IP/MPLS network a dying beast, i.e. the
IP/MPLS network will consist of LER's interconnected by MPLS-TP LSP's?

-- 
Per Carlson

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 22:05:07 -0000

Thanks Sasha,
 
Ah, one of my favourites this one.  I nearly mentioned it earlier....but
now you bring it up let's look at it.
 
You said:
 
Well I disagree, ATM could have been top-of-stack.....it for sure had
intentions of being this, this is what the AALs were all about.
Remember the B-ISDN aspirations of the 90s?  But like all 'one
mode/technology can do-it-all' visions it was doomed to failure.  We
need all 3 modes working in concert.
 
FR/ATM interworking is the classic peer interworking example.  The good
news is that both FR and ATM at least belong to the same mode, ie
co-ps...so there should be some DP/CP synergies.  The DP struggles quite
a bit though (eg traffic units quite different sizes/functional
compostion, FR has BECN ATM has not, OAM not the same) and the CP is
essentially non-existent wrt matching.  Hmmm....not very then good
really.   But then we come to the significant bit of the clients
supported in the DP.  When it comes to the stream applications there is
essentially handwaving here.  But then ATM did have aspirations of
top-of-stack but FR did not.  So when you look closely this its hardly a
shining example of peer interworking.
 
regards, Neil

________________________________

	From: Alexander Vainshtein
[mailto:[email-masked]] 
	Sent: 10 March 2009 20:27
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked]; Alik Shimelmits; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: Is MPLS-TP a profile of MPLS? (was: Clarifying
MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

	Neil,

	Thank you again for a prompt response. But allow me to point to
yet another potential counter-example:

		Neither FR nor ATM have ever been "top of the stack"
protocol. 
		Nevertheless, AFAIK, FRF.8 (which defines peer
interworking between FR and ATM) has been not just standardized (by the
then FR Forum) but also deployed in operational networks.

	Doesn't this fact contradict your key statement? Or did I miss
something?

	Regards,

	     Sasha

	

	________________________________________
	From: [email-masked] [[email-masked]]
	Sent: Tuesday, March 10, 2009 2:15 PM
	To: Alexander Vainshtein
	Cc: [email-masked]; Alik Shimelmits; [email-masked];
[email-masked]; [email-masked]
	Subject: RE: Is MPLS-TP a profile of MPLS? (was: Clarifying
MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))
	
	Thanks Sasha,  Good observations...let me try and address
them...in-line
	please.

	
	
	> first time!) that IP/MPLS and MPLS-TP will not ever do
peer-to-peer
	
	NH=> Sorry....but I do feel very passionate about doing the
right
	things.
	>     Your SDH example (VC4 vs. VC12) is, of course, absolutely
valid.
	
	NH=> Yes, this one is intuitively very obvious because the SDH
co-cs
	mode *forces* the quantisation/assignment of resource (due to
the co-cs
	mode using regular time-slicing/labelling of resource)....so we
can
	clearly see that a VC4 cannot 'fit' into a VC12, and things like
merging
	are simply not possible.  In other modes I do agree it is less
easy to
	figure out what the differences are.....and more worryingly IMO
it is
	also much more easy to do the wrong things 'just because it's
	possible'....which then have real operational impact later.

	NH=> This is a really great example and worth examining a little
	further.  The reason we might want to peer interwork IPv4 and
IPv6 is
	that they are both top-of-stack layer networks...and this is key
point.
	So each might be carrying the *same* message/file/stream
application
	adaptation functions, eg UDP/TCP/RTP....and it is these we want
to pass
	transparently across a peer interworking point.
	
	If one examines a non top-of-stack layer network that does not
interface
	directly with applications but instead carries a higher level
client
	network (that itself may or may not be top-of-stack) then one
can
	quickly figure out that trying to force peer interworking of non
	top-of-stack layer networks has no real practical value....it
can sure
	create a lot of unnecessary work though.

	>      such interworking, be it intentional or not.
	
	NH=> I am also very glad you brought this one up too.  It really
upsets
	me to see various technology fora like OIF, MEF and MPLSF
pushing peer
	interworking (ie UNIs/E-NNIs) in what are clearly non top-of
stack layer
	networks.  Sure I can understand why such fora might push their
	favourite technologies like this but I do not think they are
serving the
	best interests of our industry.  Perhaps only ATM was the only
	technology that could have really laid claim to 'challenging'
	IP/Internet and the PSTN as a top-of-stack layer
network....because it
	did have message/file/stream application adaptation functions in
its
	AALs.  If I look at Optical layer networks, Ethernet or indeed
MPLS they
	do *not* natively support end-system application adaptation
functions
	for message/file/stream cases.....this is not to say they can't
do so,
	but that they currently do not do so.  And when this is the
case, then
	one does not have to be a genius to go through the analysis to
show that
	peer interworking makes no sense....you might as well just fully
	terminate the (lower) networks and pass across the client
(higher) level
	network they are carrying (hopefully in a proper client/server
manner).

	> hear what other people think about it all.
	
	NH=> I understand why you are worried.  Whilst we have folks
pushing
	incorrect architectural ideas then we are going to have
downstream
	problems.  Forcing peer interworking when a non top-of-stack
layer
	network is indeed not a good idea IMO.....but think it through
for
	yourself, IMO its obvious why this should be true but I accept
this
	might not be so obvious for everyone.
	
	BTW - This is not simply just a technical issue....though the
technical
	arguments stand on their own merit.  There can be
legal/regulatory
	considerations for operators in some countries.  So whilst those
	advocating peer interworking of non top-of-stack layer networks
can be
	quietly ignored on purely technical grounds, it is very serious
issue
	for those operators who may be subject to legal/regulatory
pressures to
	provide such interconnects.  And this is one reason why I take
this
	topic very seriously.
	
	regards, Neil

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 10 Mar 2009 22:18:24 +0000

On 10/03/2009 21:20, "Per Carlson" <[email-masked]> wrote:

> a IP/MPLS domain.

Interconnected by or interconnected over? I see no requirement to peer MPLS
and MPLS-TP. I can see use cases for using one as the server layer (i.e. To
transport) the other.

> That raised the question how a MPLS-TP LSP, with

OAM is only once piece of the puzzle. In this scenario of MPLS over MPLS-TP
the client could compensate (with some constraints) for a lack of server OAM
by running its own OAM.

In general when a provider is buying capacity to link two MPLS-TP device it
is upto the provider to ensure that capacity is delivered such that it is
suitable for them to use. Different providers may have different standards
of suitable depending on a raft of things including the service they are
ultimately offering. I believe it is possible to constrain (or engineer) an
MPLS network to be able to act as a server layer for MPLS-TP however not all
MPLS networks deployed today are constained or engineer such that they are
suitable.

> IP/MPLS network will consist of LER's interconnected by MPLS-TP LSP's?

This is why I push for backwards compatibility across functions within the
MPLS-TP toolset as I want to have the option to evolve my existing MPLS
deployments as appropriate not build from new.

Ben

---

From: <[email-masked]>
Date: Tue, 10 Mar 2009 22:36:13 -0000

Thank you Greg.
 
I think I understand your point here.  I belive you are essentially
saying this:  I have a DP layer network specification (any
mode/technology) and it should be possible for me to use CP X and MP Y
in different instantiations of this DP layer network.  That is perfectly
sensible/reasonable.  Where we have, however, to reach some agreement in
standards is when we want to peer-interwork a given layer
network.......the DP is a given here, so the key issues surround the CP
(the MP is usually a no-go area for interworking) and we usually
restrict what can be seen/controlled across such an (E-NNI) interface.  
 
But please be very clear that such interworking between operators is
really only necessary for networks that are top-of-stack and that
support real (external) message/file/stream applications.....so this is
normally public services like the Internet or the PSTN.  To create
UNIs/E-NNIs in arbitrary non top-of-stack layer networks is quite
baffling.  Sure it is technically possible, but what is the real purpose
of it?  When we get to the ends of such an arrangement all we can do is
pass the client layer network across transparently, whether it is
top-of-stack or not.
 
regards, Neil

	From: Greg Mirsky [mailto:[email-masked]] 
	Sent: 10 March 2009 21:14
	To: Harrison,N,Neil,CXM R
	Cc: [email-masked];
[email-masked]; [email-masked]
	Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was:
Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

	Dear Sasha, Neil and All,
	I hope that I can clarify situation regarding requirement #16 as
proposed by Verizon's team. Andy have explained that "non-homogeneous
domains" refers not to interworking between MPLS-TP and IP/MPLS domains
but interworking of CP and MP across homogeneous DP based on MPLS-TP (I
wish I got it right!). The picture that I've carried from our exchange
is that some MPLS-TP domains might use GMPLS signalling while others
will be NMS-provisioned. Additional requirement - ability to provision
MPLS-TP path across such non-homogeneous (in provisioning sense)
domains.
	
	Regards,
	Greg
	
	[snip]
	[snip]

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 10 Mar 2009 20:30:29 -0700

Neil,
your explanation makes the it easier to picture. But I'm only the messenger,
or more precise, an interpreter on behalf of the Verizon team. I think that
the E-NNI in this scenario will be between Verizon's own domains that might
use different planes to provision the MPLS-TP path. In such case, I think,
an operator might use and benefit from sensible interworking since they
control both sides even though the network is not top-of-the-stack.

Regards,
Greg

On Tue, Mar 10, 2009 at 3:36 PM, <[email-masked]> wrote:

>  Thank you Greg.
>
> I think I understand your point here.  I belive you are essentially saying
> this:  I have a DP layer network specification (any mode/technology) and it
> should be possible for me to use CP X and MP Y in different instantiations
> of this DP layer network.  That is perfectly sensible/reasonable.  Where we
> have, however, to reach some agreement in standards is when we want to
> peer-interwork a given layer network.......the DP is a given here, so the
> key issues surround the CP (the MP is usually a no-go area for interworking)
> and we usually restrict what can be seen/controlled across such an (E-NNI)
> interface.
>
> But please be very clear that such interworking between operators is really
> only necessary for networks that are top-of-stack and that support real
> (external) message/file/stream applications.....so this is normally public
> services like the Internet or the PSTN.  To create UNIs/E-NNIs in arbitrary
> non top-of-stack layer networks is quite baffling.  Sure it is technically
> possible, but what is the real purpose of it?  When we get to the ends of
> such an arrangement all we can do is pass the client layer network across
> transparently, whether it is top-of-stack or not.
>
> regards, Neil
>
>  ------------------------------
> *From:* Greg Mirsky [mailto:[email-masked]]
> *Sent:* 10 March 2009 21:14
> *To:* Harrison,N,Neil,CXM R
> *Cc:* [email-masked]; [email-masked];
> [email-masked]
> *Subject:* Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying
> I hope that I can clarify situation regarding requirement #16 as proposed
> by Verizon's team. Andy have explained that "non-homogeneous domains" refers

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 11 Mar 2009 08:24:59 +0100

Per,

> Are a service provider implementing MPLS-TP supposed to build *another*
> MPLS network alongside any existing IP/MPLS network? 

I believe that there are/will be three networks:
3) Layer 3 public services network
2) Layer 2 packet transport network
1) Layer 1 optical transport network

The Layer 3 network supports a billion residential and business subscribers
and content providers.

The Layer 2 network supports the Layer 3 network and L2 customers (business,
carrier-carrier, wholesale).

The Layer 1 network supports the Layer 3 and Layer 2 networks and L1
customers (business, carrier-carrier, wholesale).

15 years ago there was the PSTN (voice/fax) as Layer 3 network and the
PDH/SDH as Layer 1 network.

Today we have the PSTN (voice/fax) and NGN (voice/data) as Layer 3 networks,
a mix of Ethernet and MPLS as Layer 2 networks and SDH/OTN as Layer 1
networks.

In the future I expect that we will have NGN+ (voice/data/video) as Layer 3
network, PTN as Layer 2 network and OTN as Layer 1 network. PTN will contain
a mix of traffic engineered Ethernet VLAN and MPLS-TP. The PTN supports a
different set of clients than the NGN+, with very different connectivity
characteristics, SLAs and numbers. It is best to separate the PTN from the
NGN+. 

Such is obvious for those that base their PTN on Ethernet... i.e. Ethernet
devices are needed to support the PTN and IP/MPLS devices are need to
support the NGN+.

It is less obvious for those that deploy MPLS-TP in the core of their PTN...
i.e. it looks as if one can use the same devices to support both NGN+ core
(which require IP/MPLS) and PTN core (which deploys MPLS-TP). Both are using
MPLS technology, so can't these two (very different) core networks be
combined... at least one operator has recently decided that the answer is
no.

In parallel to the NGN+ and PTN build ups, there is the emerging OTN. With
the growth of traffic in the PTN I see more and more "optical bypasses"
being added into the PTN. Those optical bypasses bypass the PTN core, and
establish direct interconnect of PTN S-PE nodes via the emerging multi
service OTN. As soon as two S-PEs have a few Gbit/s of data to exchange it
is cost effective to set up such optical bypass. Especially with the
addition of an ODU0 (1.2 Gbit/s) to the OTN specifications this will become
more and more attractive.

The NGN aggregation network will be riding over the PTN metro ethernet
network (MEN). The NGN's IP traffic is e.g. carried in PPPoE over a C-VLAN
to the DSLAMs. The C-VLANs are carried through the MEN and delivered to the
DSLAMs. The MEN aggregates the C-VLANs into S-VLAN tunnels. The NGN core
network aggregates the IP traffic into MPLS LSPs and carries those LSPs
through the NGN core. With growing traffic optical bypasses will be added
and fat LSPs are carried directly via the OTN core.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Per Carlson
Sent: dinsdag 10 maart 2009 22:21
To: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying
MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

Hi Sasha.

>> So, unfortunately, I remain worried... and I'd be happy to hear what 
>> other people think about it all.

Worried might be a to strong word, but I'm at least a bit confused about the
direction of MPLS-TP regards to IP/MPLS.

During the MPLS & Ethernet congress in Paris lasth month, at least one
presenter showed slides where MPLS-TP domains where interconnected by a
IP/MPLS domain. That raised the question how a MPLS-TP LSP, with need of
strong OAM, could be delivered over a less (OAM) capable network. Wouldn't
that break the whole picture? If I have interpret your arguments correctly
Neil, my question seams valid.

The "answer" on the question raises another question: Are a service provider
implementing MPLS-TP supposed to build *another* MPLS network alongside any
existing IP/MPLS network? Isn't reducing the number of diverse networks
(e.g. SDH/SONET and IP/MPLS) one of the success factors today (reducing
CapEx and OpEx)? How would running two packet-oriented MPLS-based networks
in parallel be a good thing? Or are the traditional LSR's in a IP/MPLS
network a dying beast, i.e. the IP/MPLS network will consist of LER's
interconnected by MPLS-TP LSP's?

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 11 Mar 2009 08:26:45 +0100

Sasha,
 
You are right. The requirement is that client must be the same.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Alexander Vainshtein
Sent: dinsdag 10 maart 2009 21:27
To: [email-masked]
Cc: Alik Shimelmits; [email-masked]
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying
MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

Neil,

Thank you again for a prompt response. But allow me to point to yet another
potential counter-example:

Neither FR nor ATM have ever been "top of the stack" protocol. 
Nevertheless, AFAIK, FRF.8 (which defines peer interworking between FR and
ATM) has been not just standardized (by the then FR Forum) but also deployed
in operational networks.

Regards,

     Sasha

________________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, March 10, 2009 2:15 PM
To: Alexander Vainshtein
Cc: [email-masked]; Alik Shimelmits; [email-masked]; [email-masked];
[email-masked]
Subject: RE: Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP
requirements for MPLS(-TP) overMPLS(-TP))

regards, Neil

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 11 Mar 2009 08:37:56 +0100

Neil,
 
I believe that the question was to interconnect an MPLS-TP network operated
with a MP only (no CP) and an MPLS-TP network operated with both MP and CP.
Such interconnection between operators is absolutely common practice. E.g.
we also have this in SDH today where some SDH networks ae operated using MP
and CP and others are operated using MP only.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: dinsdag 10 maart 2009 23:36
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying
MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

Thank you Greg.

 
regards, Neil

  _____  

Cc: [email-masked]; [email-masked];

Regards,
Greg

[snip]
[snip]

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 11 Mar 2009 09:13:13 +0100

Greg,
 
I assume that you are not concerned about the interworking of the DP in both
domains; i.e. both domains have the MPLS-TP DP. Correct?
 
When I look at SONET/SDH transport networks, then I know that there are
domains in these networks that are operated with MP only, and there are
domains that are operated with MP and CP. Can we use this hybrid control
model as basis for the operation of a MPLS-TP network with MP only and MP/CP
controlled domains? Example: STS-1 connection set up using MP in metro
domain and GMPLS in core domain.
 
Regards,
Maarten

  _____  

Of Greg Mirsky
Sent: woensdag 11 maart 2009 4:30

Neil,

Regards,
Greg

Thank you Greg.

 
regards, Neil

  _____  

Regards,
Greg

[snip]
[snip]

---

From: Per Carlson <[email-masked]>
Date: Wed, 11 Mar 2009 11:07:25 +0100

> and MPLS-TP. I can see use cases for using one as the server layer (i.e. To

Not sure of the difference of "by" and "over" here. The slides I'm
referring to is number 14,15 and 18 in the presentation George Swallow
held on Day One. Slide 18 clearly shows interworking of LSP/PW's in
MPLS-TP and IP/MPLS, and I can't imaging how this will *not* break the
MPLS-TP paradigm (strong OAM, no ECMP, no PHP, etc.).

> the client could compensate (with some constraints) for a lack of server OAM

Yes, OAM is just one piece, but IMHO the one that make or break the
picture. The other constraints on the DP (e.g. no ECMP and no PHP) are
far easier to handle.

> MPLS networks deployed today are constained or engineer such that they are

ACK.

> deployments as appropriate not build from new.

Can't argue about that, but my worry/concern is that MPLS-TP diverges
so far from IP/MPLS that a evolution of the later is not realistic.
Reading what Neil Harrison is saying does not calm my worry/concern.
I'm not stating Neil is right/wrong here (because a lot of it are far
over my head), but just trying to give the view of things from a
medium sized service provider (running both SDH and IP/MPLS today).

-- 
Per Carlson

---

From: "Malcolm Betts" <[email-masked]>
Date: Wed, 11 Mar 2009 09:23:57 -0400

All, first a clarification, I think that this fragment of the thread is
now on the topic of interconnection between administrative domains in
the same layer network - i.e. both networks are MPLS-TP.  Note that
these administrative domains may be within the same network operator or
they may be different network operators.
 
So considering the 3 planes and combinations:
 
Data Plane (including DP OAM) - no issues (after we have defined
MPLS-TP)
 
Control plane in A to Control plane in B - need to exchange routing and
signalling information to support path setup/tear down.  The appropriate
policies must be applied at the NNI to limit the scope of the
information exchanged.  I think that this will be a part of the work on
the MPLS-TP control plane.
 
Management plane - excluding path set up/tear down - no need for any
exchange of information.
 
Management plane path set up/tear down - can be achieved via human
interaction or web based tools via a firewall.
 
Now for the "interesting" case of path set up/tear down:
 
Administration A CP - Administration B - MP (with a manual process):
The practical problem is the difference in time frame for an automated
process (CP in A) and a manual process (MP in B).  
I am aware that the TMForum have defined (in MTNM v3.5) an "asymmetric"
exchange i.e. an OSS (MP) can request a CP to set up/tear down
connections and be kept informed of the status of the connections.  I am
not aware of any work to support a CP request to a MP to set up/tear
down connections.

Malcolm Betts 
Nortel Networks 
Phone: +1 613 763 7860 (ESN 393) 
email: [email-masked] 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Maarten Vissers
Sent: Wednesday, March 11, 2009 4:13 AM
To: 'Greg Mirsky'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying
MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

Greg,
 
I assume that you are not concerned about the interworking of the DP in
both domains; i.e. both domains have the MPLS-TP DP. Correct?
 
When I look at SONET/SDH transport networks, then I know that there are
domains in these networks that are operated with MP only, and there are
domains that are operated with MP and CP. Can we use this hybrid control
model as basis for the operation of a MPLS-TP network with MP only and
MP/CP controlled domains? Example: STS-1 connection set up using MP in
metro domain and GMPLS in core domain.
 
Regards,
Maarten

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Mirsky

Neil,
your explanation makes the it easier to picture. But I'm only the
messenger, or more precise, an interpreter on behalf of the Verizon
team. I think that the E-NNI in this scenario will be between Verizon's
own domains that might use different planes to provision the MPLS-TP
path. In such case, I think, an operator might use and benefit from
sensible interworking since they control both sides even though the
network is not top-of-the-stack.

Regards,
Greg

	Thank you Greg.
	 
	I think I understand your point here.  I belive you are
essentially saying this:  I have a DP layer network specification (any
mode/technology) and it should be possible for me to use CP X and MP Y
in different instantiations of this DP layer network.  That is perfectly
sensible/reasonable.  Where we have, however, to reach some agreement in
standards is when we want to peer-interwork a given layer
network.......the DP is a given here, so the key issues surround the CP
(the MP is usually a no-go area for interworking) and we usually
restrict what can be seen/controlled across such an (E-NNI) interface.  
	 
	But please be very clear that such interworking between
operators is really only necessary for networks that are top-of-stack
and that support real (external) message/file/stream applications.....so
this is normally public services like the Internet or the PSTN.  To
create UNIs/E-NNIs in arbitrary non top-of-stack layer networks is quite
baffling.  Sure it is technically possible, but what is the real purpose
of it?  When we get to the ends of such an arrangement all we can do is
pass the client layer network across transparently, whether it is
top-of-stack or not.
	 
	regards, Neil

		
		Cc: [email-masked];
[email-masked]; [email-masked]
		Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS?
(was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

		Dear Sasha, Neil and All,
		I hope that I can clarify situation regarding
requirement #16 as proposed by Verizon's team. Andy have explained that
"non-homogeneous domains" refers not to interworking between MPLS-TP and
IP/MPLS domains but interworking of CP and MP across homogeneous DP
based on MPLS-TP (I wish I got it right!). The picture that I've carried
from our exchange is that some MPLS-TP domains might use GMPLS
signalling while others will be NMS-provisioned. Additional requirement
- ability to provision MPLS-TP path across such non-homogeneous (in
provisioning sense) domains.
		
		Regards,
		Greg
		
		[snip]
		[snip]

---

From: Alexander Vainshtein <[email-masked]>
Date: Wed, 11 Mar 2009 15:49:06 +0200

Malcolm,

To me, the generic question (as formulated in the subject, i.e. Is MPLS-TP a profile of MPLS?) still remains open and stands on its own.
One of the critical specific aspects of this generic question peer interworking between IP/MPLS and MPLS-TP. Its importance stems from the fact that MPLS-TP and IP/MPLS packets cannot be distinguished in the DP, and it is increased by the perception that MPLS-TP may be relegated to "access rings" interconnected over IP/MPLS core.

The "weak" definitions of interoperability that have appeared on this thread do help much either, IMO.

Interworking between different domains of MPLS-TP (with some using the CP and some only MP) is, IMHO and FWIW, a different issue. It is definitely worth discussion, but I would suggest to split it to a different thread.

My 2c,
    Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm Betts
Sent: Wednesday, March 11, 2009 3:24 PM
To: [email-masked]
Cc: Alik Shimelmits
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

All, first a clarification, I think that this fragment of the thread is now on the topic of interconnection between administrative domains in the same layer network - i.e. both networks are MPLS-TP.  Note that these administrative domains may be within the same network operator or they may be different network operators.

Data Plane (including DP OAM) - no issues (after we have defined MPLS-TP)

Control plane in A to Control plane in B - need to exchange routing and signalling information to support path setup/tear down.  The appropriate policies must be applied at the NNI to limit the scope of the information exchanged.  I think that this will be a part of the work on the MPLS-TP control plane.

Management plane - excluding path set up/tear down - no need for any exchange of information.

Management plane path set up/tear down - can be achieved via human interaction or web based tools via a firewall.

Administration A CP - Administration B - MP (with a manual process):
The practical problem is the difference in time frame for an automated process (CP in A) and a manual process (MP in B).
I am aware that the TMForum have defined (in MTNM v3.5) an "asymmetric" exchange i.e. an OSS (MP) can request a CP to set up/tear down connections and be kept informed of the status of the connections.  I am not aware of any work to support a CP request to a MP to set up/tear down connections.

Malcolm Betts
Nortel Networks

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Maarten Vissers
Sent: Wednesday, March 11, 2009 4:13 AM
To: 'Greg Mirsky'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

Greg,

I assume that you are not concerned about the interworking of the DP in both domains; i.e. both domains have the MPLS-TP DP. Correct?

When I look at SONET/SDH transport networks, then I know that there are domains in these networks that are operated with MP only, and there are domains that are operated with MP and CP. Can we use this hybrid control model as basis for the operation of a MPLS-TP network with MP only and MP/CP controlled domains? Example: STS-1 connection set up using MP in metro domain and GMPLS in core domain.

Regards,
Maarten

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Greg Mirsky
Sent: woensdag 11 maart 2009 4:30
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

Neil,
your explanation makes the it easier to picture. But I'm only the messenger, or more precise, an interpreter on behalf of the Verizon team. I think that the E-NNI in this scenario will be between Verizon's own domains that might use different planes to provision the MPLS-TP path. In such case, I think, an operator might use and benefit from sensible interworking since they control both sides even though the network is not top-of-the-stack.

Regards,
Greg

On Tue, Mar 10, 2009 at 3:36 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Thank you Greg.

I think I understand your point here.  I belive you are essentially saying this:  I have a DP layer network specification (any mode/technology) and it should be possible for me to use CP X and MP Y in different instantiations of this DP layer network.  That is perfectly sensible/reasonable.  Where we have, however, to reach some agreement in standards is when we want to peer-interwork a given layer network.......the DP is a given here, so the key issues surround the CP (the MP is usually a no-go area for interworking) and we usually restrict what can be seen/controlled across such an (E-NNI) interface.

But please be very clear that such interworking between operators is really only necessary for networks that are top-of-stack and that support real (external) message/file/stream applications.....so this is normally public services like the Internet or the PSTN.  To create UNIs/E-NNIs in arbitrary non top-of-stack layer networks is quite baffling.  Sure it is technically possible, but what is the real purpose of it?  When we get to the ends of such an arrangement all we can do is pass the client layer network across transparently, whether it is top-of-stack or not.

regards, Neil

________________________________
From: Greg Mirsky [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 10 March 2009 21:14

To: Harrison,N,Neil,CXM R
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

Dear Sasha, Neil and All,
I hope that I can clarify situation regarding requirement #16 as proposed by Verizon's team. Andy have explained that "non-homogeneous domains" refers not to interworking between MPLS-TP and IP/MPLS domains but interworking of CP and MP across homogeneous DP based on MPLS-TP (I wish I got it right!). The picture that I've carried from our exchange is that some MPLS-TP domains might use GMPLS signalling while others will be NMS-provisioned. Additional requirement - ability to provision MPLS-TP path across such non-homogeneous (in provisioning sense) domains.

Regards,
Greg

[snip]
[snip]

---

From: <[email-masked]>
Date: Wed, 11 Mar 2009 14:09:04 -0000

Sasha,
 
Yes I understand your question. 
"Is MPLS-TP a profile of MPLS?) still remains open and stands on its
own"
 
If MPLS-TP did not introduce any changes to the DP and just pruned what
already existed then you could say it was profile of MPLS.  However, I
hasten to add 'but what is MPLS now?', as LDP_MPLS != RSVP_MPLS !=
BGP4_MPLS....and in the case of LDP there can be many spins of that.
This was the point I made previously about a MPLS traffic unit only
having context in terms of the protocol that issued it, ergo MPLS is not
singular even today.
 
However, we can clearly state that MPLS-TP does indeed add something new
to the DP because it will have PID function here.  So it can't be
profile of existing MPLS but it can be an enhanced version of MPLS that
tries to re-use as many parts as possible (even when they are not so
great like the CW) and it now can have the GMPLS CP because we can run
this under the GAL.  MPLS-TP also does not really have PWs any
more....we have removed the behaviours that created these....now we just
have MPLS-TP LSPs.
 
Irrespective of all this, I still maintain that non top-of-stack layer
networks should not be interworked as peers...sure you can do it (we can
all sorts of things) and I don't see any real benefits here, but I do
see problems.
 
regards, Neil

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Alexander Vainshtein
	Sent: 11 March 2009 13:49
	To: Malcolm Betts
	Cc: Alik Shimelmits; [email-masked]
	Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS?(was:
Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

	Malcolm,
	 
	To me, the generic question (as formulated in the subject, i.e.
Is MPLS-TP a profile of MPLS?) still remains open and stands on its own.
	One of the critical specific aspects of this generic question
peer interworking between IP/MPLS and MPLS-TP. Its importance stems from
the fact that MPLS-TP and IP/MPLS packets cannot be distinguished in the
DP, and it is increased by the perception that MPLS-TP may be relegated
to "access rings" interconnected over IP/MPLS core.
	 
	The "weak" definitions of interoperability that have appeared on
this thread do help much either, IMO.
	 
	Interworking between different domains of MPLS-TP (with some
using the CP and some only MP) is, IMHO and FWIW, a different issue. It
is definitely worth discussion, but I would suggest to split it to a
different thread.
	 
	My 2c,
	    Sasha

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Malcolm Betts
		Sent: Wednesday, March 11, 2009 3:24 PM
		To: [email-masked]
		Cc: Alik Shimelmits
		Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS?
(was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

		All, first a clarification, I think that this fragment
of the thread is now on the topic of interconnection between
administrative domains in the same layer network - i.e. both networks
are MPLS-TP.  Note that these administrative domains may be within the
same network operator or they may be different network operators.

		Data Plane (including DP OAM) - no issues (after we have
defined MPLS-TP)
		 
		Control plane in A to Control plane in B - need to
exchange routing and signalling information to support path setup/tear
down.  The appropriate policies must be applied at the NNI to limit the
scope of the information exchanged.  I think that this will be a part of
the work on the MPLS-TP control plane.
		 
		Management plane - excluding path set up/tear down - no
need for any exchange of information.
		 
		Management plane path set up/tear down - can be achieved
via human interaction or web based tools via a firewall.

		Administration A CP - Administration B - MP (with a
manual process):
		The practical problem is the difference in time frame
for an automated process (CP in A) and a manual process (MP in B).  
		I am aware that the TMForum have defined (in MTNM v3.5)
an "asymmetric" exchange i.e. an OSS (MP) can request a CP to set
up/tear down connections and be kept informed of the status of the
connections.  I am not aware of any work to support a CP request to a MP
to set up/tear down connections.

		Malcolm Betts 
		Nortel Networks 

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Maarten Vissers
		Sent: Wednesday, March 11, 2009 4:13 AM
		To: 'Greg Mirsky'
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS?
(was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

		Greg,
		 
		I assume that you are not concerned about the
interworking of the DP in both domains; i.e. both domains have the
MPLS-TP DP. Correct?
		 
		When I look at SONET/SDH transport networks, then I know
that there are domains in these networks that are operated with MP only,
and there are domains that are operated with MP and CP. Can we use this
hybrid control model as basis for the operation of a MPLS-TP network
with MP only and MP/CP controlled domains? Example: STS-1 connection set
up using MP in metro domain and GMPLS in core domain.
		 
		Regards,
		Maarten

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Greg Mirsky
		Sent: woensdag 11 maart 2009 4:30
		To: [email-masked]
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] Is MPLS-TP a profile of MPLS?
(was: Clarifying MPLS-TP requirements for MPLS(-TP) overMPLS(-TP))

		Neil,
		your explanation makes the it easier to picture. But I'm
only the messenger, or more precise, an interpreter on behalf of the
Verizon team. I think that the E-NNI in this scenario will be between
Verizon's own domains that might use different planes to provision the
MPLS-TP path. In such case, I think, an operator might use and benefit
from sensible interworking since they control both sides even though the
network is not top-of-the-stack.
		
		Regards,
		Greg

		On Tue, Mar 10, 2009 at 3:36 PM,
<[email-masked]> wrote:

			Thank you Greg.
			 
			I think I understand your point here.  I belive
you are essentially saying this:  I have a DP layer network
specification (any mode/technology) and it should be possible for me to
use CP X and MP Y in different instantiations of this DP layer network.
That is perfectly sensible/reasonable.  Where we have, however, to reach
some agreement in standards is when we want to peer-interwork a given
layer network.......the DP is a given here, so the key issues surround
the CP (the MP is usually a no-go area for interworking) and we usually
restrict what can be seen/controlled across such an (E-NNI) interface.  
			 
			But please be very clear that such interworking
between operators is really only necessary for networks that are
top-of-stack and that support real (external) message/file/stream
applications.....so this is normally public services like the Internet
or the PSTN.  To create UNIs/E-NNIs in arbitrary non top-of-stack layer
networks is quite baffling.  Sure it is technically possible, but what
is the real purpose of it?  When we get to the ends of such an
arrangement all we can do is pass the client layer network across
transparently, whether it is top-of-stack or not.
			 
			regards, Neil

				From: Greg Mirsky
[mailto:[email-masked]] 
				Sent: 10 March 2009 21:14 

				Cc: [email-masked];
[email-masked]; [email-masked]
				Subject: Re: [mpls-tp] Is MPLS-TP a
profile of MPLS? (was: Clarifying MPLS-TP requirements for MPLS(-TP)
overMPLS(-TP))

				Dear Sasha, Neil and All,
				I hope that I can clarify situation
regarding requirement #16 as proposed by Verizon's team. Andy have
explained that "non-homogeneous domains" refers not to interworking
between MPLS-TP and IP/MPLS domains but interworking of CP and MP across
homogeneous DP based on MPLS-TP (I wish I got it right!). The picture
that I've carried from our exchange is that some MPLS-TP domains might
use GMPLS signalling while others will be NMS-provisioned. Additional
requirement - ability to provision MPLS-TP path across such
non-homogeneous (in provisioning sense) domains.
				
				Regards,
				Greg
				
				[snip]
				[snip]