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

[Maarten Vissers <[e-mail]>]

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.

	[Note - We need to understand what the IETF equivalent of the ITU-T
Access Point
      is... See below the '-----' for my view on this based on a question I
received
      on what the equivalent ITU-T construct would be for an IETF
'interface'.]

The MPLS-TP data plane does not demarc the boundary between those layer
networks or between a layer and its sublayers. This is a clear difference
with similar layer/sublayer structures in OTN ODU and Ethernet ETH layers;
in those two technologies there is a clear demarcation between layer
networks and between the layer network signal and its sublayers. But we have
to ask ourselves the question if this would be an issue... Most likely not
because of the following:

Transport Service, Transport Path and Section layer names represent roles in
a domain. A Transport-LSP in domain A can be passed through a domain B in
which it is considered to be a Service-LSP. Similarly, a Section-LSP in
domain A can be passed through a domain B in which it is considered to be a
Service-LSP. And it is even possible to have a Section-LSP in domain A which
is passed through a domain B as Service-LSP and is then handed of to domain
C as a Transport-LSP.

This role variability is also present in the OTN ODU and Ethernet ETH
layers, so there is commonality between those three technologies at this
point.

The implication is that the Access Point in e.g. a MPLS-TP Section layer or
Ethernet Virtual Section layer could be connected with an Access Point in a
MPLS-TP Transport Path or Ethernet Virtual Path layer. This capability is of
course a feature and not a bug, and the implication is that the access point
identification scheme should be agnostic to the operational role names of
the layer networks in each domain.

-----------

I was asked the question what the ITU-T equivalent of the IETF 'interface'
would be.
It could be that this equivalent is the 'access point'. The access points
demark a trail in a layer network and access points are identified by means
of their 'access point identifier (APId)'. If you look at clause 8.6.1 in
G.7710 http://www.itu.int/rec/T-REC-G.7710-200707-I/en then you find in
figure 23 a description of how the APId is used to identify the other
reference points (termination connection point, connection point).

In G.831 http://www.itu.int/rec/T-REC-G.831-200003-I/en you find the
following features of the access points:
----------
The features of Access Point Identifiers (APIs) are:
- each access point identifier must be globally unique in its layer network;
- where it may be expected that the access point may be required for path
set-up across an inter-operator boundary, the access point identifier must
be available to other network operators; - the access point identifier
should not change while the access point remains in existence; - the access
point identifier should be able to identify the country and network operator
which is responsible for routing to and from the access point; - the set of
all access point identifiers belonging to a single administrative layer
network should form a single access point identification scheme; - the
scheme of access point identifiers for each administrative layer network can
be independent from the scheme in any other administrative layer network.

The API shall begin with either the country code as defined in ITU-T E.164
(one, two or three numeric characters) or, the three alphabetic character
country code as defined in ISO 3166.
The remainder of the API characters that follow the country code shall be a
matter for the organization to whom the country code has been assigned,
provided that uniqueness is guaranteed.
These characters may be any alphanumeric characters as defined in ITU-T T.50
(International Reference Version - 7-bit coded character set for information
interchange).
The alphanumeric character set consists of the characters "a" to "z", "A" to
"Z", and "0" to "9".
In the case where the API uses less than fifteen characters, the API will be
padded (extended) with the T.50 "NUL" character to get a fifteen byte
character string.
------------


Applying this AP, CP and TCP identification in MPLS-TP you would get the
following:

- PW access points demark the PW trail
- PW termination connection points demark the PW network connection

- LSP access points demark the LSP trail
- LSP termination connection points demark the LSP network connection

A PW trail and network connection are identified (PW_TID, PW_NCID) by means
of their PW APId set <PW_APId_1, PW_APId_2> for a p2p PW and <PW_APId_1,
PW_APId_2, .., PW_APId_n> for a p2mp PW.

A LSP trail and network connection are identified (LSP_TID, LSP_NCID) by
means of their LSP APId set <LSP_APId_1, LSP_APId_2> for a p2p LSP and
<LSP_APId_1, LSP_APId_2, .., LSP_APId_n> for a p2mp LSP.


- a LSP carries one or more client LSPs and/or PWs and/or VPLSs. 
The client LSP connection points are identified by means of the LSP APId
plus the client_LSP label value. 
The client PW connection points are identified by means of the LSP APId plus
the client_PW label value. 
The client VPLS (i.e. ETH) flow points are identified by means of the LSP
APId plus the client_VPLS (i.e. PW) label value.

- a PW may carry one or more client LSPs. 
The client LSP connection points are identified by means of the PW APId plus
the client_LSP label value. 

- a PW may carry one or more client VLANs. 
The client VLAN (i.e. ETH) flow points are identified by means of the PW
APId plus the client_VLAN VLAN ID (VID) or Service instance ID (SID) value. 

The client connection/flow points demark a client link connection.
A client_LSP or _VLAN link connection supported by a PW trail is then
identified by the PW trail identifier (i.e.
<PW_APId_1,PW_APId_2(,...,PW_APId_n)> plus the client label or VID/SID
value.
A client_LSP/PW/VPLS link connection supported by a LSP trail is then
identified by the LSP trail identifier (i.e.
<LSP_APId_1,LSP_APId_2(,...,LSP_APId_n)> plus the client LSP or PW label
value (LSP__LCID, PW_LCID, VPLS_LCID).

A PW (or LSP) trail contains of one or more PW (or LSP) link connections
with unique identifiers. This implies that one PW (or LSP) trail/network
connection identifier is related to a set of PW (or LSP) link connection
identifiers; e.g. PW_TID/PW_NCID <=> {PW_LCID_a,PW_LCID_b, ...}

------------

PWs and LSPs represent layer network trails and sublayer network trails in
the MPLS-TP Transport Service, Transport Path and Section layer networks. An
overview:

Transport Service layer network:
- MPLS-TP PW trail
- MPLS-TP service-LSP trail
[- ETH VPLS connectionless trail]
- MPLS-TP PST-LSP sublayer trail

Transport Path layer network:
- MPLS-TP transport-LSP trail
- MPLS-TP PST-LSP sublayer trail

Section layer network:
- MPLS-TP section-LSP trail
- MPLS-TP PST-LSP sublayer trail

Note that the PST-LSP sublayer trails performing a TCM function are
dependent on the layer trails. If a layer trail is deleted all associated
PST-LSP sublayer trails have to be deleted as well.

In MPLS-TP these sublayer trails perform a complete encapsulation of the
layer trail and/or client-sublayer trail. This is different from sublayer
trails in SDH, OTN, ATM and Ethernet networks. In those latter network
technologies a sublayer trail just adds an additional level of OAM without
further encapsulating the incoming signal. As a consequence in those latter
networks the addition or removal of a sublayer does not change the set of
link connections in the trail/network connection. In MPLS-TP we have to
decide if we follow the same model, or if we consider that the addition of a
sublayer (i.e. a PST-LSP) changes the number of link connections in the
layer trail/network connection. 

Regards,
Maarten


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] 
Sent: woensdag 21 april 2010 9:38
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: RE: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

Maarten...agreed...but there is also a worrying addressing problem in all
this IMO that does not seem to be recognised/understood.  In summary, a
layer network (any mode/technology, not just co-ps/MPLS-TP
say) is most essentially characterised by its access point addressing
scheme...screw this up on day 1 and it is very hard to change later.

MPLS originally never had proper addressing allocated to it...largely due to
is binding with the cl-ps mode IP layer network it could never be seen as a
layer network in its own right (part of the common control-plane flaw - I
come back on this later).  Further, each LSP here was a *sublayer* and part
of the same hybrid/MPLS/IP layer network.
Moreover, each LSP (label distribution) signalling type created its own form
of addressing for how it wanted to identify its type of access points.

PWs made the situation significantly worse when they became multi-hop.
These suddenly jumped from an adaptation role to a full blown layer network
in their own right.  So they needed their own addressing scheme (and OAM,
LDP signalling, etc),...which is what all the AII stuff is.
Not a great addressing structure I should add, we should have used v4 or
v6 but the problem dogging this stuff was that we were still claiming this
was all part of the same IP/MPLS layer network => can also read as same
instance of routing.....something we should know now is a flawed notion for
MPLS-T based on lessons learnt from GMPLS (I originally pointed this 'common
CP nonsense' out at 2000 San Diego IETF mtg).

Now MPLS-TP is supposed to be a transport network.  So each LSP in a nested
case should be in its own layer network....this is essentially what you
shown below.  MPLS-TP therefore does not need sublayering as per the old
type of MPLS...and it for sure should not be generating a PW layer network,
that simply indicates a failure to deliver a transport network and just
propagates the error made in MPLS.

However, because some folks want to retain the S bit notion and the old type
of sublayering in MPLS-TP, we have no way of knowing whether a set of nested
LSPs belong to different layer networks or are sublayers in some arbitary
layer network grouping.  The DP looks the same in all cases.

I can see all sorts of problems brewing here in correctly identify which
layer network a given LSP belongs to...esp if there are multiple parties
involved in both client/server and peer-partition sense. 

regards, Neil   

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Maarten Vissers
> Sent: 21 April 2010 08:11
> To: 'George Swallow'; [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]
> Subject: Re: [mpls-tp] [mpls] mpls wg last call on
> draft-ietf-mpls-tp-identifiers-01
> 
> George,
> 
> It is a bad practice to identify a connection (e.g. LSP) within the 
> scope of their server layer trail (e.g. tunnel LSP). Reason is that a 
> connection (e.g. LSP) is typically carried by multiple server layer 
> trails (e.g. tunnel LSPs).
> Example: a service-LSP X is carried over three transport-LSPs A,B,C:
> 
>    |<----------------service-LSP_X------------------->|
>     |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->|
> 
> It is possible to reroute this service-LSP and change it as follows:
> 
>    |<----------------service-LSP_X------------------->|
>     |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->|
> 
> or as follows:
> 
>    |<----------------service-LSP_X------------------->|
>     |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->|
> 
> The service-LSP X is still the same service-LSP with the same 
> service-LSP MEP functions, only the path through the MPLS-TP network 
> has been changed.
> 
> Identification with respect to the server layer trail (e.g. 
> tunnel LSP) is appropriate for a link connection (e.g. LSP segment). 
> The service-LSP X has three service-LSP segments.
> Those segments are identified with respect to their tunnel; i.e. with 
> respect to the transport-LSP in this example.
> 
> Regards,
> Maarten
> 
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]] On Behalf Of George Swallow
> Sent: vrijdag 16 april 2010 18:45
> To: Attila Takacs; Loa Andersson; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]
> Subject: Re: [mpls-tp] [mpls] mpls wg last call on
> draft-ietf-mpls-tp-identifiers-01
> 
> 
> 
> 
> On 4/2/10 2:53 AM, "Attila Takacs" <[e-mail]> wrote:
> 
> > Hi Matthew and George,
> > 
> > Please find some comments/questions below.
> > 
> > -In Section 5.1 you have:
> > 
> > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num
> > 
> > What is the reason of having a Dst-Tunnel_Num besides the
> Src-Tunnel_Num?
> 
> Existing implementations of RSVP-TE have used the tunnel space as 
> global to the node.  It is difficult if not impossible to coordinate 
> such spaces between nodes.  In RSVP-TE the coordination does not 
> matter, since the tail end of the tunnel doesn't have a real interface 
> - it only receives and usually with a PHP of the tunnel label, so the 
> packets only belong to the physical interface.
> 
> In a bidirectional world, separate tunnel spaces at the two ends 
> becomes useful.
> 
> If this independence is not need is some environments then one can 
> configure just one value and use it in both fields.
> 
> > Is it there to support associated unidirectional
> Tunnels/LSPs? If so
> > it should be called out in the text.
> 
> That was not my original intent, but you are quite correct that this 
> would be very useful.  Particularly if the associated tunnels pass 
> through a share mid-point somewhere along the path.
> 
> > Same applies to the globally unique case.
> 
> Of course.
> 
> > -In Section 5.2 you simply append one LSP_Num to the above. 
> This is a
> > bit confusing to me, if there are Src/Dst Tunnel_Nums then two 
> > LSP_Nums would be needed too, wouldn't it?
> 
> Once, you have independent tunnel-ids, coordination of the LSP numbers 
> becomes easy.  It also could be used to allow the two ends to readily 
> identify which is working and which is protection.
> 
> > -In Section 5.3 Mapping to GMPLS signaling does not use the 
> > Dst-Tunnel_Num. So this means that we may have two
> different tunnels
> > identified with
> > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this
> intentional, e.g., the associated unidirectional case?
> 
> For the associated unidirectional, this works perfectly.  For 
> bidirectional, I was thinking of two options.
> 
> 1)  Strict binding  -  both ends are configure with the full 
> identifier and will only accept the connection if everything matches.
> 
> 2)  Dynamic binding - Source signals with just its Tunnel_Num.  RESV 
> message would carry back the destination's tunnel_num.  Note that both 
> ends need both pieces for some of the OAM to work.
> 
> > This should be clarified.
> 
> I'll see what I can do.  But this is not supposed to the MPLS-TP 
> signaling draft.
>  
> > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether.
> 
> I'm planning to keep it.
>  
> > -Section 7 has a note saying to be aligned with the OAM
> fwk, is this
> > still to be done?
> 
> Yes.  That draft is also being updated.  We appear to be converging.
> 
> > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs.
> > How would Tunnel and LSP MEGs be used? What OAM would run at the 
> > Tunnel level and not at the LSP level?
> >
> > Do we need Tunnel MEG_IDs as defined in 7.1.2.1?
> 
> I had been told early on that MEGs were needed for tunnels.  
> Now getting comments that they are not (same comment is in the ITU 
> liaison).  So I planning to remove it, unless I hear other opinions.
> 
> > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too.
> 
> See above.
> 
> > -Section 8 talks about open issues? When will these be addressed?
> 
> Before it is re-issued.  Goal is end of next week.
> 
> ...George
> 
> > Thanks,
> > Attila
> 
> _______________________________________________
> mpls-tp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>