Subject: Re: [mpls-tp] [mpls] RFC 5586: Intermediate nodes on MPLS Section

From: <[email-masked]>
Date: Wed, 27 Jan 2010 11:01:00 -0000

Snipped and re-sending as I got a bounce indication due to original
length

________________________________

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 27 January 2010 10:57
	To: 'Greg Mirsky'; Maarten Vissers
	Cc: [email-masked]; Alexander Vainshtein; [email-masked]
	Subject: RE: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on
MPLS Section

	Some care is going to need to be exercised here...why?  Well, I
was on the MPLS-TP audio-conf call yesterday that considered 2 issues
(both that I have raised previously):
	-    what does the term 'network layer' mean?
	-    why should MS PWs exist in MPLS-TP?
	 
	Wrt to the latter item the technical issue here is that PWs are
an artefact of the architectural conditions imposed by the LDP form of
MPLS, and since LDP is not used in MPLS-TP then PWs are not technically
required in MPLS-TP.  Furthermore, we should not create a new (PW) co-ps
mode layer network above MPLS-TP (which is what MS PWs represent) just
because we can.  A very closely related issue is the difference between
(i) true client/server LSP layering and (ii) nested LSP sublayering that
we find in MPLS today and identified from the setting of the S bit (note
that the former demands different routing instances per client and
server whilst the latter assumes the same instance of routing across the
sublayers)
	 
	What became clear from the ensuing discussion is (this is only a
subset of conclusions reached):
	-    the above is technically accurate, ie if we were designing
MPLS-TP without the history there would be no need to create PWs
	-    MS PWs are optional
	-    (and the key point wrt this thread) MPLS-TP will allow both
(i) nested LSPs as we find in MPLS today (sublayering, same layer
network) and (ii) true client/server LSPs (true layering, different
layer networks) to exist....the choice is down to the network
operator...and *maybe both these cases can appear in the same stack of
nested headers* (?)
	 
	I am not quite sure how one can distinguish cases (i) and (ii)
from just looking at DP headers, but the key point I wanted to make here
is that in case (ii) there must be no snooping of the client layer
network as transparency and client/server layer network functional
decoupling are essential (this observation applies to all client/server
cases).  Note carefully that in MPLS as-is one cannot tell the implied
semantic of a label just from looking at the DP header, one has to know
the context of the label (ie essentially which 'signalling' protocol
issued it) to know this.  Note also that TCM is a form of sublayering
and one can justify snooping here *iff* one is sure of the semantic of
the higher level header (especially the label). 
	 
	I think there could be some quite interesting problems in a
multi-party networking scenario due to this sublayering/layering
flexibility.  My personal view is that a transport network does not
require sublayering.
	 
	regards, Neil
________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Greg Mirsky
	Sent: 26 January 2010 21:04
	To: Maarten Vissers
	Cc: [email-masked]; Alexander Vainshtein; [email-masked]
	Subject: Re: [mpls] [mpls-tp] RFC 5586: Intermediate nodes on
MPLS Section

		Dear Maarten,
		I think that your scenarios are based on the following
assumption you're making "The existing mpls switch ports will only be
able to look at inner labels of packets of which the outer label is
terminated; new mpls switch ports will be able to look at inner labels
of all packets (my underline); this is a similar evolution as we got in
ethernet... " I don't think that is the direction where MPLS-TP should
go and will go.
		
		Regards,
		Greg