Subject: Re: [mpls-tp] [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01

From: <[email-masked]>
Date: Sat, 24 Apr 2010 09:11:08 +0100

Colleagues:  From private mails I have received it is quite clear that
the term 'tunnel' is misunderstood, and I am not at all surprised why
Maarten is confused and seeking clarification on this......see if this
helps:
 
Tunnel means the following IMO:
 
A cl-ps technique where one IP traffic unit is fully encapsulated in
another IP traffic unit and where either:
 
-    a true client/server relationship exists between the inner and
outer traffic units, ie they belong to different layer networks, ie
different access point addressing domain, different routing domain,
etc....or
 
-    a sublayering relationship exists between the inner and outer
traffic units, ie they belong to same layer network, ie same access
point addressing domain, same routing domain, etc.  Note that the key
purpose of this 2nd case is so that nodes in the same layer network do
not have to know where certain addresses lie within the topology....and
they usually do not have routing information to reach those addresses.
This was THE key reason tunnels were originally devised.

Now none of this really relates to MPLS....esp in a pukka co-ps mode
sense (where we can forget the additional architectural problems the LDP
spin of MPLS creates).  Here we are not dealing with simple child
traffic unit encap relationships but the layering/sublayering
relationships between different parent connections.  And as I have
stated many times before, sublayering via the S bit as a per 'classic
MPLS' makes no sense whatsoever in a co-ps mode transport network....but
then neither do PWs, TTL, etc.  So we do not have the same tunnel case
in MPLS-TP as per the original IP cl-ps case.
 
I also think MPLS-TP should stop calling itself a 'transport network'
because it plainly isn't....it's simply a partial arch fix of MPLS
as-is.
 
regards, Neil

________________________________

	From: Harrison,N,Neil,DKQ7 R 
	Sent: 23 April 2010 08:52
	To: 'Maarten Vissers'; 'George Swallow';
[email-masked]
	Cc: [email-masked]
	Subject: RE: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

	Maarten....I think you will find there is no simple/definitive
(all cases) view of what a 'tunnel' is.  As you should know, there are
significant distinctions in how the 3 network modes work.  This is all
down to the physics of how one carves up time/space/freq resource
partitions and labels these....and where short cuts on labelling can be
taken IFF one does not violate the rules of a connection in the
co-ps/co-cs modes...these labelling short cuts (specifically => absolute
SA, absolute DA, client PID) are NOT possible in the cl-ps mode.
	 
	I am not even sure pursuing the definition of what a tunnel is
is even worthwhile for MPLS-TP.  A major problem with MPLS-TP IMO is
that it is being pulled in too many directions.....and right now for
folks to claim this is a transport network is a bit rich IMO.  A fairly
serious problem IMO is the lack of understanding that sublayering using
the S bit (as per old MPLS) is a really bad idea for a transport
network.  Start digging into this technically and you start to see the
common CP nonsense, lack of proper addressing, etc that I mentioned in
my previous mail.  These are the key issues IMO...not trying to
retrospectively fit the moving target of what a tunnel is into the more
rigorous G.800 framework of modelling networks.
	 
	CF the definition of the 'L3 network layer' from OSI....anyone
who understands networking well enough should know what a nonsense this
is....yet it is still used/abused all the time....I see the use of the
term tunnel in a similar vein.  It's origins lie in IP cl-ps networking
as a simple client/server encaps at the *traffic unit* level (because
there is no parent connection entity here).
	 
	regards, Neil

________________________________

		From: Maarten Vissers
[mailto:[email-masked]] 
		Sent: 23 April 2010 07:58
		To: 'George Swallow'; [email-masked]
		Cc: Harrison,N,Neil,DKQ7 R; [email-masked]
		Subject: RE: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

		George,
		 
		Let me try to explore the issue a bit further using an
example of a SNC protected LSP.

/-- w.cp -- Adaptation -- w.sl-ap -- TT -- w.sl-tcp -- LC -- cp --
		ap --TT -- tcp -- MC -- cp -- LC -- cp -- MC
	
\-- p.cp -- Adaptation -- p.sl-ap -- TT -- p.sl-tcp -- LC -- cp --
		 
		|<-------------------------------------- LSP tunnel
------------------------------------------------------------------------
--------------------------
		|<-------------------------------------- LSP trail
------------------------------------------------------------------------
------------------------------
	
|<------------------------------------LSP network connection
------------------------------------------------------------------
	
|<------------- Working LSP subnetwork connection ------------------
	
|<--- Working PST-LSP sublayer trail ---- 
	
|<--- W.PST-LSP tunnel ----------------------
		TT=Trail Termination
|<------------- Prot. LSP subnetwork connection -----------------------
	
|<--- Prot. PST-LSP sublayer trail ---------
	
|<--- P.PST-LSP tunnel ------------------------
	
|<--- this is not a tunnel as it does not associate with a trail ----
		 
		If a Tunnel is equivalent with a Trail or Sublayer
Trail, then I would not associate the term tunnel with the working LSP
subnetwork connection (SNC) and protection LSP subnetowrk connection
pair. 
		 
		If you want to identify each component of a LSP
tunnel/trail then this can be done by listing the set of LSP link
connections (LC) and LSP matrix connections (MC) that are part of the
LSP trail and give this set a LSP netowrk connection (NC) identifier. 
		It is then possible to also group the LSP LCs and LSP
MCs which make up the working SNC and protection SNC and then give those
two SNCs an identifier.
		 
		I assume that you need these identifiers for some
administrative reason related to connection management... correct?
		E.g. LSP NC (ID=X) = {LC #a, MC #b, LC #c, MC #d, W.SNC
#e, P.SNC #f, MC #g, LC #h}
		with W.SNC (ID=e) = {LC #e1, MC #e2, LC #e3} and
		P.SNC (ID=f) = { LC #f1, MC #f2, LC #f3, MC #f4, LC
#f5}.
		 
		If IDs 'e' and 'f' could be arbitrary values, or could
be a common value plus an extension; e.g. 'e' = <Y.Z1> and 'f' = <Y.Z2>.
		It is possible to refer to this common value 'Y[' as a
Tunnel identifier value, but in this case a Tunnel represents an
arbitrary set of link connections and matrix connections of a trail.
Examples are the LSP NC Tunnel and the LSP W.SNC + LSP P.SNC Tunnel. It
would also be possible to associate a Tunnel ID with the unprotected
part of the trail as this is also a LSP SNC.
		 
		I hope this helps us to identify what a Tunnel is and
what the application is that demands the definition of this Tunnel
construct.
		 
		Regards,
		Maarten

________________________________

		From: George Swallow [mailto:[email-masked]] 
		Sent: donderdag 22 april 2010 22:29
		To: Maarten Vissers; [email-masked]
		Cc: [email-masked]; [email-masked]
		Subject: Re: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

		Maarten -
		
		Not sure I get your question.  A Tunnel could include a
working-LSP and a protection-LSP.  A PST would be a separate tunnel.
Either the working-LSP or the protection-LSP could be routed over a PST
or multiple PSTs.
		
		The model we have has the working and protection LSPs
beginning and ending co-incident with the tunnel.
		
		...George

		On 4/21/10 9:45 AM, "Maarten Vissers"
<[email-masked]> wrote:

			George,
			
			Do you envisage that a Tunnel could include a
working-PST-LSP and a protection-PST-LSP? 
			Or would there be two Tunnels in such case:
Tunnel A including the working-PST-LSP and Tunnel B including the
protection-PST-LSP?
			
			Regards,
			Maarten

________________________________

			From: George Swallow [mailto:[email-masked]] 
			Sent: woensdag 21 april 2010 14:59
			To: [email-masked]; Maarten Vissers
			Cc: [email-masked]; [email-masked]
			Subject: Re: [mpls-tp] [mpls] mpls wg last call
on draft-ietf-mpls-tp-identifiers-01
			
			Malcomb -
			
			In my terminology a PST would be a Tunnel with
one (unprotected) LSP.  The OAM, as you point out, is run on the LSP.
			
			...George

			On 4/21/10 8:39 AM, "[email-masked]"
<[email-masked]> wrote:

				Maarten, 
				
				Your point about "layer networks"  in
MPLS-TP was discussed at the expert's meeting last week.  The
conclusion that we reached, is that these are not layer networks but
"administrative roles" that a network operator can assign to a layer or
sub-layer.  A network operator is free to assign all, some or none of
these roles.  Also a given layer or sub-layer may be assigned a
different  role in different domains.  Text has been added to G.8110.1
to describe  this. 
				
				I think that the points you make about
the need to assign  identifiers to the various reference points is
valid, and we can group  (MPLS-TP) sub layers (e.g. those established
for monitoring, protection) into  one "administrative role". 
				
				Below you talk about a PST-LSP, as I
pointed out in a previous response, it is not clear if a PST is a tunnel
or a  LSP.  One thing that is clear (to me) is that OAM can run on a LSP
but it  cannot run on a tunnel.  
				
				Regards, 
				
				Malcolm  
				
				[email-masked] wrote on
21/04/2010 05:06:07 AM:
				
				> Neil,
				> 
				> There are three  MPLS-TP layer
netowrks defined:
				> 1) Transport Service layer  network
				>    (including MS-PWs, Service-LSPs,
PST-LSPs)
				> 2) Transport Path layer network
				>     (including Transport-LSPs,
PST-LSPs)
				> 3) Section  layer network
				>    (including Section-LSPs,
PST-LSPs).
				> 
				> Each of those three MPLS-TP layer
networks has two  types of sub-layers
				> defined:
				> A) TCM sub-layer with a 1:1  relation
(for admin domain monitoring
				>    and SNC/S  protection switching
applications)
				> B) TCM sub-layer with a n:1  relation
(for some protection switching
				> applciations)
				> which  are supported by PST-LSPs.
				> 
				> The three layer networks have  Access
Points, and those APs are identified by
				> means of an Access  Point Identifier. 
				> 
				> The sub-layers have sub-layer Access
Points, and those sub-layer APs are
				> identified by means of a sub-layer
Access Point Identifier.
				>------------snip

---

From: George Swallow <[email-masked]>
Date: Thu, 29 Apr 2010 10:14:01 -0400

Shahram -

See inline

On 3/11/10 7:27 PM, "Shahram Davari" <[email-masked]> wrote:

> Hi,
> 
> Couple of comments:
> 
> 1) Why the Interface_ID is 32-bit while the Tunnel_ID is 16-bit? Do we need to
> support more interfaces than tunnels?

GS:  Planning to change scope of Tunnel_ID.  Just needs to be unique in the
context of the Session Object as defined in 3209 with source address used as
the extended tunnel-id

> 2) The draft defines the Global_Tunnel_ID as:
>       Src-Global_ID::Src-Node_ID::Src-Tunnel_Num::
> Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num
> 
> This seems to define a bidirectional tunnel. Is that the intent? If so please
> clarify. If not then why Dst-Global_ID::Dst-Node_ID::Dst-Tunnel_Num is needed?
> 
GS: The scope is bidirectional.  But I suppose it can be applied to
unidirectional as well.  I still don¹t understand the requirement for
unidirectional  seems to be that bidirectional with 0 data-bandwidth in the
reverse direction would do better as you would have a return path for OAM
and DCC etc.
> 
> 3) Is section 5.2 talking about unidirectional LSP or bidirectional LSP?
> 
GS: Ditto
> 
> 4) Section 7.1.2.1 says:
>         Since a MEG pertains to a single MPLS-TP Tunnel, IP compatible MEG_IDs
> for MPLS-TP Tunnels are simply the corresponding Tunnel_IDs
> 
> Assuming the Tunnel_ID is a unidirectional ID, then this statement implies
> that for the reverse direction a different MEG_ID is required. Is that the
> intent? If so why?
> 
GS: Not unidirectional!
> 
> 5) Why are drafts part of the normative references?
> 
Cut and paste error actually!  Thanks for pointing it out!
> 
> 6) Will section 8 (open issues) be removed before publishing? This section
> implies that the MEP and MIP definition is not yet aligned with framework?
> 
GS: Yes
> 
> Regards,
> Shahram
> 
> 
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Loa
> Andersson
> Sent: Thursday, March 11, 2010 3:33 PM
> To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01
> 
> All,
> 
> this is to start an MPLS working group last call on
> There is a discussion on the OAM model for MS-PWs where we haven't been
> able to come to conclusion. Once we reach agreement the document will
> be updated. Comments in this area are welcome during the working group
> last call.
> 
> 
> Please send your comments to the [email-masked] mailing list.
> 
> The working group last ends eob April 2nd.
> 
> /Loa
> 
> --
> 
> Loa Andersson
> 
> Sr Strategy and Standards Manager
> Ericsson ///
>    phone:  +46 10 717 52 13
>            +46 767 72 92 13
> 
>    email:  [email-masked]
>            [email-masked]
> 
> 
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
> 
> 
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>