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

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 26 Jan 2010 21:36:00 +0200

Maarten and all,
I resend this message since the original one has exceeded the moderators' limit (40K).
I've snipped the tail of the thread.

Regards,
     Sasha
________________________________
From: Alexander Vainshtein
Sent: Tuesday, January 26, 2010 4:48 PM
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,
IMHO and FWIW, OAM must follow what the data plane (which, in the case of MPLS is label-based) does.
If MEG levels (and adjacencies) are not bound to data plane adjacencies, what are these MEGs about?

Regards,
     Sasha

________________________________
From: Maarten Vissers [mailto:[email-masked]]
Sent: Tuesday, January 26, 2010 4:44 PM
To: Alexander Vainshtein
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Sasha,

See inline..

________________________________
From: Alexander Vainshtein [mailto:[email-masked]]
Sent: dinsdag 26 januari 2010 9:38
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,
I apologize for a delayed response.
I think that the example you've given actually confirms my point of view: your model does not work with the regular MPLS data plane.
Here is my analysis of your logic, based on the assumption that all LSPs are P2P and downstream label allocation is used. The conclusions would not change if

 1.  <Maarten> The MPLS-TP LSP OAM inserted by the lower blue MEP in node P-left has as top and bottom of stack the GAL [[Sasha]] OK. This implies that S-PE-left looks on the labeled packets it receives from P-Left, otherwise it would simply ignore GAL

[maarten2] The S-PE-left has a MPLS-TP blue MEP function at its input and this blue MEP function will look for packets with as top label the GAL.

 1.  <Maarten> The MPLS-TP LSP OAM inserted by the higher blue MEP in node P-left has as top of stack the label inserted by the lower blue MEP (identified as LSE) and as bottom of stack the GAL... The interface port in the S-PE-left port will swap the top of stack label of non-OAM and TTL not-expired packets [[Sasha]] This implies that the top label in this stack has been allocated by S-PE-Left, bound by it to a certain FEC, and this binding "distributed" (no matter by which means) to P-Left. Were it not so, the label placed by the higher blue MEP on top of the label stack in a labeled packet P-left sends to S-PE-left would be treated by the latter as invalid, and the packet would be discarded - see RFC 3031, Section 3.18. And this, in its turn, means that S-PE-Left is adjacent to P-Left : it allocates and binds to FECs labels that P-left puts on top of the stack in labeled packets that from its point of view, belong to these FECs. In your example the FEC in question is formed by the packets that should go to PE-right, and the conclusion is that PE-right is NOT adjacent to PE-Left.

[maarten2] There are two MEG levels (bindings) in the Section layer:
A. P-left to S-PE-left
B. P-left to P-right.
For the A. binding P-left and S-PE-left are adjacent. They share one Maintenance Entity Group (MEG) level and monitor this Section MEG by means of two Section MEP functions.
For the B. binding P-left and P-right are  adjacent. They share one Maintenance Entity Group (MEG) level and monitor this Section Segment MEG by means of two Section Segment MEP functions.

The bottom line, IMHO and FWIW, that adjacency in the MPLS data plane (and, by implication, in the MPLS-TP one) is directly related to the label allocation and label-to-FEC binding. If we can agree on that, this should be explicitly mentioned in the MPLS-TP Framework document to prevent misunderstanding.

[maarten2]  There are multiple adjacencies in the MPLS and MPLS-TP (and any other) data plane.
Those adjacencies are Maintenance Entity Groups and are represented by their MEG levels.
For OAM the MEG type of adjacencies are relevant, not the label type adjacencies.
A server layer or server sublayer MEG type adjacency has a 1-to-1 relationship with a label type adjacency.
A label identifies one 'link connection' within a 'network connection', in the blue Section layer, the label used on the link between P-left and S-PE-left identifies one of the three link connections that establish the Section layer network connection, which latter is monitored by the Section MEG.

[maarten2] I understand that there are two types of adjacencies to recognize and specify in MPLS-TP. I suggest that we specify both explicitly and that we describe the relationship between these two adjacencies. This will prevent further misunderstandings.

Regards,
Maarten

Regards,
     Sasha

---

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 26 Jan 2010 21:41:30 +0200

Maarten and all,
I resend this message since the original one has exceeded the moderator's limit.
I've snipped the tail of the email thread.
Regards,
     Sasha
________________________________
From: Alexander Vainshtein
Sent: Tuesday, January 26, 2010 5:31 PM
To: Maarten Vissers
Cc: [email-masked]; [email-masked]
Subject: RE: [mpls-tp] RFC 5586: Intermediate nodes on MPLS Section

Maarten,
You are saying (not for the first time) that the same OAM model equally applies to all data planes. I think that this is fundamentally incorrect: one size does not fit all.

Y.1731 inherited its definitions of MEGs and such with IEEE 802.1ag which dealt exclusively with the networks build by 802.1-compliant switches (a.k.a. "learning bridges") with their specific data plane.

The data plane of MPLS (and MPLS-TP) is very much different.

Regards,
     Sasha

Sent: Tuesday, January 26, 2010 5:23 PM

Sasha,

Below the definitions of a MEG and ME from Y.1731. It are the basic architecture components for OAM.
OAM frames exist within one MEG, and determine the status/performance of the MEG.
An MEG exists within the bounds of a transport entity.

In MPLS-TP a MEG is bound to a MS-PW and to a LSP.
In the example, the "Section layer transport path" is provided by an LSP, which is monitored by the top blue MEG.
The "Section layer transport path segment" between P-left and S-PE-left is provided by either an unlabeled or priority labelled LSP, which is monitored by the bottom blue MEG.
This "Section layer transport path segment" may be unmonitored (as illustrated in mplstp-connection-concepts-06w.pdf), and in this case there is no MEG and there is no LSP.

Regards,
Maarten

---

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