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

From: Attila Takacs <[email-masked]>
Date: Fri, 2 Apr 2010 08:53:43 +0200

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? 
Is it there to support associated unidirectional Tunnels/LSPs? If so it should be called out in the text. 

Same applies to the globally unique case.

-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?

-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? This should be clarified.

Hmm, maybe the Dst-Tunnel_Num should be omitted altogether.

-Section 7 has a note saying to be aligned with the OAM fwk, is this still to be done?

-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?

-Section 7.1.2.2, the Dst-Tunnel_Num question applies here too.

-Section 8 talks about open issues? When will these be addressed?

Thanks,
Attila 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Loa Andersson
> Sent: Friday, March 12, 2010 12:33 AM
> 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
> draft-ietf-mpls-tp-identifiers-01
> 
> 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
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 2 Apr 2010 08:58:01 +0200

Hi,
   Some more comments from me more ore less on the same route as Attila.

·         Section 1.1

o        PSC is also used as Packet Switching Capable for OSPF-TE 

·         Section 2

o        Tunnel I think that here a reference to the actual identifier of the quoted entity could help I mean a reference to Section 5

·         Section 4 

o        would be good to have a short explanation why numbered interfaces are not in the scope of MPLS-TP 

·         Section 5

o        Even if section 2 points to 3209 than the Tunnel Identifier chosen is different from what is defined in 3209, Extended Tunnel ID field is missing while there are two different Tunnel Num that is not clear how they works.  I think here the same convention used in 3209 and in GMPLS signaling would be good to avoid to have two or more Tunnel identifiers for MPLS-TP networks using GMPLS. 

o        Why MPLS-TP tunnels must be associated to a LIH?  Why MPLS-TP tunnels need to be configured as FA? Does that imply that in case OSPF-TE is used it must advertise MPLS-TP tunnels as FA each time a new tunnel is created?

·         Section 5.2 I think that sentence "The format of a Tunnel_ID is:" should be "The format of a LSP_ID is:" same for the globally unique case.

·         Section 5.3 addresses some of my above concern about usage of tunnel and lsp identifiers even if is not a 1:1 mapping given that the Dst-Tunnel_Num is not mapped in GMPLS Tunnel ID

·         Remaining of the docs is still WP

BR

Diego

 line

DIEGO CAVIGLIA 
Strategic Product Manager 

Ericsson Italy
Product Line PAIB
Via A. Negrone 1/A
Genoa, Italy
Phone +390106003736
Mobile +393357181762
[email-masked]
www.ericsson.com 

 Ericsson

This Communication is Confidential. We only send and receive email on the basis of the term set out at www.ericsson.com/email_disclaimer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Attila Takacs
Sent: venerdì 2 aprile 2010 8.54
To: Loa Andersson; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls] mpls wg last call on draft-ietf-mpls-tp-identifiers-01

Hi Matthew and George,

Thanks,
Attila

---

From: Sriganesh Kini <[email-masked]>
Date: Fri, 2 Apr 2010 09:11:41 -0400

Hi,

1) section 5.1 - "At each endpoint a tunnel is uniquely identified by the Source Node_ID and a locally assigned tunnel number."
   a) Should "Source" be replaced by the "endpoint's" since later the "Dst-Node_ID" is used?
   b) Useful to clarify the scope of "uniquely identified" before this statement. 
   C) Should there be a similar identifier at each intermediate node besides the endpoints?

2) Section 5.2 - Does any LSR own the "LSP_num" space? If so pls state that.

Thanks

- Sri

> Sent: Thursday, March 11, 2010 3:33 PM

---

From: George Swallow <[email-masked]>
Date: Fri, 16 Apr 2010 12:45:25 -0400

> 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.

> 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

Yes.  That draft is also being updated.  We appear to be converging.

> 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

> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 09:11:02 +0200

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: [email-masked] [mailto:[email-masked]] On Behalf
Of George Swallow
Sent: vrijdag 16 april 2010 18:45
To: Attila Takacs; Loa Andersson; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

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?

> -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?

 

I'm planning to keep it.

See above.

...George

---

From: <[email-masked]>
Date: Wed, 21 Apr 2010 08:37:43 +0100

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   

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 21 April 2010 08:11
> To: 'George Swallow'; [email-masked]; [email-masked]; 
> 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:
> 
> 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
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of George Swallow
> To: Attila Takacs; Loa Andersson; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]
> 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.
> 
> 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.
> 
> 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.
> 
> I'll see what I can do.  But this is not supposed to the 
> MPLS-TP signaling draft.
>  
> > -Section 7 has a note saying to be aligned with the OAM 
> fwk, is this 
> > still to be done?
> 
> 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.
>

---

From: [email-masked]
Date: Wed, 21 Apr 2010 04:46:55 -0400

Maarten,

I agree with the point that you made below.  However, my interpretation of 
the identifiers draft is that a LSP is named from a tunnel and in this 
context the tunnel is not the server LSP.

During discussion of G.8110.1 at the experts meeting last week we 
attempted to clarify this by adding the following text to describe a 
tunnel in the first paragraph of clause 6.2 MPLS-TP Layer Network:

"The MPLS-TP layer network provides the transport of adapted information 
through a MPLS-TP trail between MPLS-TP access points. The logical 
association between these points is called a tunnel in the MPLS-TP RFCs. A 
tunnel is associated with one or more LSPs. The tunnel is one of the 
primary constructs that is identified and it is used to identify the LSPs 
that are associated with it, see [IETF tp-ident] for further details"

As described in the ITU comments on the identifiers draft this point is 
not clear.  It is made more obscure by the use of the term Path Segment 
Tunnel - which appears to be a LSP that is established to monitor a 
segment of a LSP.

Regards,

Malcolm

Maarten Vissers <[email-masked]> 
Sent by: [email-masked]
21/04/2010 03:11 AM

To
'George Swallow' <[email-masked]>, [email-masked], [email-masked], 
[email-masked], [email-masked]
cc

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:

or as follows:

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-----

> 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.

If this independence is not need is some environments then one can 
configure
just one value and use it in both fields.

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.

Of course.

bidirectional,

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.

 

I'm planning to keep it.

See above.

...George

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 11:06:07 +0200

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: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 21 april 2010 9:38
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
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.

regards, Neil   

> To: 'George Swallow'; [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> 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).
> service-LSP MEP functions, only the path through the MPLS-TP network 
> has been changed.
> 
> 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
> 
> 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 
> In a bidirectional world, separate tunnel spaces at the two ends 
> becomes useful.
> 
> configure just one value and use it in both fields.
> 
> 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.
> 
> message would carry back the destination's tunnel_num.  Note that both 
> ends need both pieces for some of the OAM to work.
> 
> I'll see what I can do.  But this is not supposed to the MPLS-TP 
> signaling draft.
>  
> 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.
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 11:28:12 +0200

Malcolm,
 
Thank you for informing me about the usage of 'tunnel' in MPLS-TP. This is
very different from what I could expect.
 
Looking at the text that you have added to clause 6.2/G.8110.1, I must admit
that this still leaves a question with me. Specifically the sentence "A
tunnel is associated with one or more LSPs." is not understood by me. 
 
Is the "or more" part referring to the use of multiple L-LSPs to transport
client traffic containing multiple CoS levels? If so, a 'tunnel' is
associated with one E-LSP; correct?
 
Or is this 'tunnel' construct intended within the context of ECMP? In e.g.
SDH VCAT we could then say that the VCAT 'tunnel' represents the set of VC-n
trails which provide the VCAT group. True?
 
It might be necessary to describe the identification of trails, network
connections, link connections and sub-layeer trails in ITU-T terminology
(using e.g. access point identifiers as described in my response to Neil
this morning) and in IETF terminology in an annex to G.8110.1. Then there
will be no ambiguity anylonger.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 21 april 2010 10:47
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; 'George Swallow'
Subject: Re: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

Maarten, 

During discussion of G.8110.1 at the experts meeting last week we attempted
to clarify this by adding the following text to describe a tunnel in the
first paragraph of clause 6.2 MPLS-TP Layer Network: 

"The MPLS-TP layer network provides the transport of adapted information
through a MPLS-TP trail between MPLS-TP access points. The logical
association between these points is called a tunnel in the MPLS-TP RFCs. A
tunnel is associated with one or more LSPs. The tunnel is one of the primary
constructs that is identified and it is used to identify the LSPs that are
associated with it, see [IETF tp-ident] for further details" 

As described in the ITU comments on the identifiers draft this point is not
clear.  It is made more obscure by the use of the term Path Segment Tunnel -
which appears to be a LSP that is established to monitor a segment of a LSP.

Regards, 

Malcolm 

21/04/2010 03:11 AM 

To

cc

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

George,

or as follows:

Regards,
Maarten

-----Original Message-----

Of course.

I'm planning to keep it.

See above.

...George

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 12:28:31 +0200

Malcolm,
 
Some further thoughts on this use of the term 'tunnel' in MPLS-TP context
resulted in my idea that a 'tunnel' in IETF would be represented by what we
would call a 'group' in ITU-T. Would this be a good translation?
 
We have VC-n Group (VCG) to represent the group of VC-n trails within a
VCAT. 
Along the same lines, we could refer to a LSP tunnel' as a LSP
Group'(LSPG)'.
And if we have a similar construct for PWs, then we would get in addition a
'PW Group (PWG)'.
 
In the functional model we would see then adaptation functions with multiple
Access Points, connecting to multiple termination functions if we follow the
VCAT principle. Or should we define a new termination function that has
multiple access points and multiple termination connection points? Such LSPG
or PWG termination function can then report the status of the group as well
as the status of the individual members of the group.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Maarten Vissers
Sent: woensdag 21 april 2010 11:28
To: [email-masked]; 'George Swallow'
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

Malcolm,

 

 
Regards,
Maarten

  _____  

Maarten, 

Regards, 

Malcolm 

21/04/2010 03:11 AM 

To

cc

Subject

George,

or as follows:

Regards,
Maarten

-----Original Message-----

Of course.

I'm planning to keep it.

See above.

...George

---

From: [email-masked]
Date: Wed, 21 Apr 2010 06:35:38 -0400

Hi Maarten,

At the ITU-T experts meeting last week some of the experts had an in depth 
knowledge of the MPLS RFCs so they were able to help us construct this 
text.  Please see in line below.

Regards,

Malcolm

21/04/2010 05:28 AM

To
[email-masked], 'George Swallow' <[email-masked]>
cc
[email-masked], [email-masked]
Subject
Re: [mpls-tp] [mpls] mpls wg last call on 
draft-ietf-mpls-tp-identifiers-01

Malcolm,

Looking at the text that you have added to clause 6.2/G.8110.1, I must 
admit that this still leaves a question with me. Specifically the sentence 
"A tunnel is associated with one or more LSPs." is not understood by me. 
[MB}  We have difficulty finding any better wording.  Part of the problem 
is that a tunnel is not created until the first LSP is established - the 
tunnel then names the LSP.  Other LSPs that are indented to convey 
information between the same points may then be added to (associated with) 
the tunnel.
 
Is the "or more" part referring to the use of multiple L-LSPs to transport 
client traffic containing multiple CoS levels?
[MB}  yes, that is one example
 If so, a 'tunnel' is associated with one E-LSP; correct?
[MB] Could be multiple if needed to carry the full set of client CoS 
levels, or for active and stand-by
 
Or is this 'tunnel' construct intended within the context of ECMP? In e.g. 
SDH VCAT we could then say that the VCAT 'tunnel' represents the set of 
VC-n trails which provide the VCAT group. True?
[MB]  I think it could apply in that case as well - but we did not discuss 
this since ECMP is out of scope for MPLS-TP
 
It might be necessary to describe the identification of trails, network 
connections, link connections and sub-layeer trails in ITU-T terminology 
(using e.g. access point identifiers as described in my response to Neil 
this morning) and in IETF terminology in an annex to G.8110.1. Then there 
will be no ambiguity anylonger.
[MB] The identifiers are defined in the identifiers draft, we could 
(should?) show a mapping to the G.8110.1 reference points, topological 
components and transport entities.
 
Regards,
Maarten

Maarten, 

Regards, 

Malcolm 

To

Subject

George,

or as follows:

Regards,
Maarten

-----Original Message-----

Of course.

I'm planning to keep it.

See above.

...George

---

From: <[email-masked]>
Date: Wed, 21 Apr 2010 11:49:32 +0100

Thanks Maarten.....have IETF agreed to all this?

regards, neil 

> From: Maarten Vissers [mailto:[email-masked]] 
> Sent: 21 April 2010 10:06
> To: Harrison,N,Neil,DKQ7 R; [email-masked]; [email-masked]; 
> 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.
> 
> -----------
> 
> 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:
> ----------
> - 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.
> ------------
> 
> 
> 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.
> 
> 
> 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.
> 
> The client LSP connection points are identified by means of 
> the PW APId plus the client_LSP label value. 
> 
> 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. 
> 
> 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:
> 
> 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
> 
> 
> To: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; [email-masked]; [email-masked]
> 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.
> 
> 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.
> 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 
> 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   
> 
> segment). 
> i.e. with 
> that this 
> LSP numbers 
> Tunnel_Num.  RESV

---

From: [email-masked]
Date: Wed, 21 Apr 2010 08:39:13 -0400

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:

>------------snip

---

From: George Swallow <[email-masked]>
Date: Wed, 21 Apr 2010 08:42:16 -0400

Maarten, Malcomb -

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

> that this still leaves a question with me. Specifically the sentence "A tunnel
> is associated with one or more LSPs." is not understood by me.
> 
What is intended by Tunnel is an abstract name for an entity that provides
connectivity between two points.  It could be a single unprotected LSP.  It
could also be the set {working lsp; protection lsp; selection at the east
end; selection at the west end}.  Nearly a year ago I started asking for the
ITU term for this and was told there really wasn¹t one.
In RSVP-TE a tunnel is an abstract connection between two endpoints.  It get
instantiated by an LSP.  It may have a path protection LSP associated with
it.   It is this usage that I was looking for, so I put the term Tunnel into
the document.

In the protection case, if one of the LSPs is being re-groomed it may have
yet another LSP.  I may re-groom the working LSP to a new working LSP;
bridge-and-roll; and teardown the old working LSP.  This procedure is
normally done when I don¹t have path protection, but could be used even if I
do.  I did not want to rule out this sort of operation when we get to GMPLS
signaling, and that I why I included the more rather that saying two for the
1:1 protected case.

Would it help if I added after the above sentence,

³In a provisioned environment, an unprotected tunnel has one LSP; a tunnel
with 1:1 or 1+1 protection has two LSPs namely a working LSP and a
protection LSP.²
> client traffic containing multiple CoS levels? If so, a 'tunnel' is associated
> with one E-LSP; correct?
> 
You are correct that the word tunnel is used in this context as well, but
not always in the strict sense you state in the last sentence above.
However, it is not my intention to bring this usage into the identifiers
document.
>  
> Or is this 'tunnel' construct intended within the context of ECMP? In e.g. SDH
> VCAT we could then say that the VCAT 'tunnel' represents the set of VC-n
In the cases I was covering, only one traffic stream is sent, and only on
one LSP is used at a time  except for the 1+1 case.  Normally ECMP is
handled only with multiple tunnels.  (FYI, the multiple L-LSPs is a sort of
exception to this, also not relevant to the identifiers document).
> (using e.g. access point identifiers as described in my response to Neil this
> morning) and in IETF terminology in an annex to G.8110.1. Then there will be
> no ambiguity anylonger.
> 
In ITU terminology Trail seems to come closest to tunnel, but I was told
that there was not a perfect match.  Would love to hear your opinions on the
relationship between Trail and LSPs and whether that matches what I mean by
tunnel.

...George
> I agree with the point that you made below.  However, my interpretation of the
> identifiers draft is that a LSP is named from a tunnel and in this context the
> tunnel is not the server LSP.
> 
> During discussion of G.8110.1 at the experts meeting last week we attempted to
> clarify this by adding the following text to describe a tunnel in the first
> paragraph of clause 6.2 MPLS-TP Layer Network:
> through a MPLS-TP trail between MPLS-TP access points. The logical association
> between these points is called a tunnel in the MPLS-TP RFCs. A tunnel is
> associated with one or more LSPs. The tunnel is one of the primary constructs
> that is identified and it is used to identify the LSPs that are associated
> with it, see [IETF tp-ident] for further details"
> 
> Sent by: [email-masked]  21/04/2010 03:11 AM
>   To

---

From: George Swallow <[email-masked]>
Date: Wed, 21 Apr 2010 08:44:07 -0400

Maarten -

What I need for the identifiers has nothing to do with VCAT.

...George

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

> We have VC-n Group (VCG) to represent the group of VC-n trails within a VCAT.
> Along the same lines, we could refer to a LSP tunnel' as a LSP Group'(LSPG)'.
> or PWG termination function can then report the status of the group as well as
> the status of the individual members of the group.
>  
> Regards,
> Maarten
> 
> 
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Maarten Vissers

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 14:51:35 +0200

Hi Malcolm,
 
You mention that a "tunnel" could represent the working and protection
transport path group.
How would this look like in a typical SNC protection case... the "tunnel"
would then represent the group of sub-layer trails between sublayer access
points?
 
Take the example of a service-LSP trail passing through e.g. 6 PE nodes
(TPE1 - SPE2 - SPE3 - SPE4 - SPE5 - TPE6) which is protected using Transport
Service SNC/S protection between nodes SPE2 and SPE5. 
- The service-LSP access points are in TPE1 and TPE6. 
- If the service-LSP is operated under the L-LSP approach, then there will
be a service-LSP Group, with e.g. 3 individual service-LSPs and for a p2p
service-LSP-group there will be two times three access points.
- The Transport Service sub-layer access points for this SNC protected
service-LSP-Group are in SPE1 and SPE5. 
- I assume that the e.g. 3 service-LSPs within the group are to be protected
as group. 
  The working service-LSP-group will then be encapsulated in a PST-LSP-Group
in line card A, and the protection service-LSP-group will be encapsulated in
a PST-LSP-group in line card B. Has such group protection been considered in
G.8110.1 already?
- On line card A there will be e.g. 3 sublayer access points associated with
working and on line card B there will be e.g. 3 sublayer access points
associated with protection.
 
What will we now have as identifiers?
1) service-LSP-group identifier (e.g. XYZ)
 
2) individual service-LSP identifiers = service-LSP-group identifier +
instance number (e.g. XYZ/1, XYZ/2, XYZ/3)
 
3) W+P-service-PST-LSP-group identifier ==> is this relative to the
service-LSP-group identifier (e.g. XYZ-sublayer_S  (XYZ/S))? Or, is this a
new independent identifier (e.g. PQR)?
 
4) individual service-PST-LSP identifiers = W+P-service-PST-LSP-group
identifier + instance number (e.g. XYZ/S/W1, XYZ/S/W2, XYZ/S/W3, XYZ/S/P1,
XYZ/S/P2, XYZ/S/P3 or PQR/W1, PQR/W2, PQR/W3, PQR/P1, PQR/P2, PQR/P3)?
 
Regards,
Maarten

  _____  

Sent: woensdag 21 april 2010 12:36

Hi Maarten, 

At the ITU-T experts meeting last week some of the experts had an in depth
knowledge of the MPLS RFCs so they were able to help us construct this text.
Please see in line below. 

Regards, 

Malcolm 

21/04/2010 05:28 AM 

To

cc

Subject

Malcolm, 

Looking at the text that you have added to clause 6.2/G.8110.1, I must admit
that this still leaves a question with me. Specifically the sentence "A
tunnel is associated with one or more LSPs." is not understood by me. 
[MB}  We have difficulty finding any better wording.  Part of the problem is
that a tunnel is not created until the first LSP is established - the tunnel
then names the LSP.  Other LSPs that are indented to convey information
between the same points may then be added to (associated with) the tunnel. 
  
Is the "or more" part referring to the use of multiple L-LSPs to transport
client traffic containing multiple CoS levels? 
[MB}  yes, that is one example 
 If so, a 'tunnel' is associated with one E-LSP; correct? 
[MB] Could be multiple if needed to carry the full set of client CoS levels,
or for active and stand-by 

  
Regards, 
Maarten 

  _____  

Maarten, 

Regards, 

Malcolm 

21/04/2010 03:11 AM 

To

cc

Subject

George,

or as follows:

Regards,
Maarten

-----Original Message-----

Of course.

I'm planning to keep it.

See above.

...George

---

From: George Swallow <[email-masked]>
Date: Wed, 21 Apr 2010 08:58:50 -0400

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:

> 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 
>

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 15:45:43 +0200

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 -

...George

Maarten, 

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

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 15:47:15 +0200

Malcolm,
 
The layer networks which we have named LO/HO/Section, VC/VP/VS,
TS/TP/Section seem all to be referring to the role of the transport entities
(inside each of those layer networks) within the viewpoint of a domain. E.g.
in a SONET domain a VC-3 was a HOVC3 and the same VC-3 passing through an
AU4 based SDH domain was a LOVC3. So even in SDH technology we already have
some notion of roles within the viewpoint of a domain.
 
The above is pushing me in the direction to consider that a layer or
sub-layer is not assigned a different role in different domains, but instead
that a transport entity within a domain A is considered to be e.g. a
LO/VC/TS layer transport entity, while in domain B it is considered to be
e.g. a HO/VP/TP layer transport entity. Do you agree that it might be better
to describe the roles from the viewpoint of a transport entity?
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 21 april 2010 14:39
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

Maarten, 

Regards, 

Malcolm

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 17:06:28 +0200

resending... original message was too long...
 
George,
 
> What is intended by Tunnel is an abstract name for an entity that provides
connectivity between two points.
 
In the functional model desccription, there are multiple reference points
defined within a transport-entity:
- access points (ap), 
- termination connection/flow points (tcp),
- connection/flow points (cp),
- sublayer access points (sl-ap) and
- sublayer termination connection/flow points (sl-tcp).
 
Note that the termination connection/flow points are connection/flow points
of which one end is connected to a termination function. I.e. a tcp  is a
cp, but a cp does not have to be a tcp.
 
An unprotected transport entity has the following sequence of such points: 
    ap - tcp - cp - cp - .. - cp - tcp - ap.
 
When there is a SNC/S protected transport entity, then the sequence of
points may be:
   ap - tcp - cp - cp - w.cp - w.sl-ap - w.sl-tcp - cp - cp - .. - cp -
w.sl-tcp - w.sl-ap - w.cp - cp - cp -tcp - ap
                            \ p.cp - p.sl-ap - p.sl-tcp - cp - cp - ..... -
cp - p.sl-tcp - p.sl-ap - p.cp / 
 
Between two access points there is a p2p trail:
   ap - p2p trail - ap
 
Between two termination connection points there is a p2p network connection:
   tcp - p2p network connection - tcp
 
Between two adjacent connection points there is a p2p link connection:
  cp - p2p link connection - cp
 
A subnetwork connection is defined between two non-adjacent (termination)
connection points; it includes one or more link connections and matrix
connections.
 
A p2p sublayer trail is defined between two sublayer access points:
  sl.ap - sublayer trail - sl.ap
 
Note that a sublayer trail is typically slaved to the layer trail. I.e. no
layer trail, then no sublayer trail.
  
In MPLS-TP the LSP construct is used to support both the layer trail and the
sublayer trail.
 
The "Tunnel is an abstract name for an entity that provides connectivity
between two points" should now be mapped onto the set of points depicted
above. Should the Tunnel construct refer to:
- connectivity between two access points?
- connectivity between two sublayer access points?
- connectivity between two connection points?
- other sets of points?

|<---------------------------------------------------Tunnel?----------------
---------------------------------------------------------------->|
    |
|
    |
|<---------------------------------------------------Tunnel?----------------
---------------------->|                    |
    |                    |
|                    |
    |                    |
|<-----------------Tunnel?----------------------------------->|
|                     |
    |                    |                    |
|               |                     |
   ap - tcp - cp - cp - w.cp - w.sl-ap - w.sl-tcp - cp - cp - .. - cp -
w.sl-tcp - w.sl-ap - w.cp - cp - cp -tcp - ap
                            \ p.cp - p.sl-ap - p.sl-tcp - cp - cp - ..... -
cp - p.sl-tcp - p.sl-ap - p.cp / 
                                             |
|
 
|<------------------Tunnel?---------------------------------- >|
 
yet another LSP.  I may re-groom the working LSP to a new working LSP;
bridge-and-roll; and teardown the old working LSP.  
 
I assume that re-grooming means that the LSP is following a different path
through the network, but keeping the same endpoints? Is this correct?
If correct, then re-grooming does not add a new LSP, it simply changes to
path through the network of the LSP.
 
If however the endpoints of the LSP change, e.g. in the protection case
above the new working-PST-LSP ends on a different line card, then there is a
new sublayer trail being created with new sublayer access points. If the
Tunnel is defined between the connection points at the outside of w.cp and
p.cp, then the Tunnel would first be extended with a 3rd PST-LSP and then
the initial working-PST-LSP is removed from the Tunnel.
 
But in this latter case the Tunnel is not between access points or sublayer
access points, but between connection points.
 
I hope this helps to come to a final conclusion on this item.
 
Regards,
Maarten

  _____  

From: George Swallow [mailto:[email-masked]] 
Sent: woensdag 21 april 2010 14:42
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, Malcomb -

Malcolm,

ITU term for this and was told there really wasn't one.

normally done when I don't have path protection, but could be used even if I

"In a provisioned environment, an unprotected tunnel has one LSP; a tunnel
with 1:1 or 1+1 protection has two LSPs namely a working LSP and a
protection LSP."

In the cases I was covering, only one traffic stream is sent, and only on
one LSP is used at a time - except for the 1+1 case.  Normally ECMP is
handled only with multiple tunnels.  (FYI, the multiple L-LSPs is a sort of
exception to this, also not relevant to the identifiers document).

...George

Regards,
Maarten

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 21 Apr 2010 17:39:43 +0200

resending  2nd time ...  earlier messages were too long  (67k, 42k) ...  
 
George,

 

 

 

  

 

 

 
Regards,
Maarten

---

From: <[email-masked]>
Date: Wed, 21 Apr 2010 17:16:36 +0100

Maarten,
 
It did arrive.  
 
I expect one of the problems here relates to what I was trying to
describe earlier wrt to the problems caused by the flawed 'common CP'
view.  This also has (some) history wrt to flawed OSI model that says
there is only a single L3 network....which we should all know is wrong.
You might also like to ask how tunnel applies to GMPLS controlled
networks?  
 
The other point in all this is agreeing what the actual addressing
format is going to be....and I don't think IETF would want to adopt ITU
practice here....but if there is client/server and (esp) peer-partition
cases with the potential for misconnectivity between them (so that is
both vertical misconnectivity (ie n=between different layers/sublayers)
and horizontal misconnectivity (ie between same layers/sublayers)) then
consistency of CI, in which I include AP addressing (eg as carried in CV
OAM say), is rather important.  Likewise for any TCM like sublayers.
 
These were the issues I was hinting at in my mail earlier today wrt to
why getting MPLS-TP addressing right and understanding the difference
between layersing and sublayering is important....but as I noted, a
transport network does not need sublayering in the original MPLS sense
IMO....but then it also does not need PWs or TTL and we still have these
;-)
 
regards, neil

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Maarten Vissers
	Sent: 21 April 2010 16:40
	To: 'George Swallow'; [email-masked]
	Cc: [email-masked]
	Subject: Re: [mpls-tp] [mpls] mpls wg last call on
draft-ietf-mpls-tp-identifiers-01

	resending  2nd time ...  earlier messages were too long  (67k,
42k) ...  
	 
	George,
	 
	> What is intended by Tunnel is an abstract name for an entity
that provides connectivity between two points.
	 
	In the functional model desccription, there are multiple
reference points defined within a transport-entity:
	- access points (ap), 
	- termination connection/flow points (tcp),
	- connection/flow points (cp),
	- sublayer access points (sl-ap) and
	- sublayer termination connection/flow points (sl-tcp).
	 
	Note that the termination connection/flow points are
connection/flow points of which one end is connected to a termination
function. I.e. a tcp  is a cp, but a cp does not have to be a tcp.
	 
	An unprotected transport entity has the following sequence of
such points: 
	    ap - tcp - cp - cp - .. - cp - tcp - ap.
	 
	When there is a SNC/S protected transport entity, then the
sequence of points may be:
	   ap - tcp - cp - cp - w.cp - w.sl-ap - w.sl-tcp - cp - cp - ..
- cp - w.sl-tcp - w.sl-ap - w.cp - cp - cp -tcp - ap
	                            \ p.cp - p.sl-ap - p.sl-tcp - cp -
cp - ..... - cp - p.sl-tcp - p.sl-ap - p.cp / 

	Between two termination connection points there is a p2p network
connection:
	   tcp - p2p network connection - tcp
	 
	Between two adjacent connection points there is a p2p link
connection:
	  cp - p2p link connection - cp
	 
	A subnetwork connection is defined between two non-adjacent
(termination) connection points; it includes one or more link
connections and matrix connections.
	 
	A p2p sublayer trail is defined between two sublayer access
points:
	  sl.ap - sublayer trail - sl.ap
	 
	Note that a sublayer trail is typically slaved to the layer
trail. I.e. no layer trail, then no sublayer trail.
	  
	In MPLS-TP the LSP construct is used to support both the layer
trail and the sublayer trail.
	 
	The "Tunnel is an abstract name for an entity that provides
connectivity between two points" should now be mapped onto the set of
points depicted above. Should the Tunnel construct refer to:
	- connectivity between two access points?
	- connectivity between two sublayer access points?
	- connectivity between two connection points?
	- other sets of points?

|<---------------------------------------------------Tunnel?------------
-------------------------------------------------------------------->|
	    |
|
	    |
|<---------------------------------------------------Tunnel?------------
-------------------------->|                    |
	    |                    |
|                    |
	    |                    |
|<-----------------Tunnel?----------------------------------->|
|                     |
	    |                    |                    |
|               |                     |
	
	   ap - tcp - cp - cp - w.cp - w.sl-ap - w.sl-tcp - cp - cp - ..
- cp - w.sl-tcp - w.sl-ap - w.cp - cp - cp -tcp - ap
	                            \ p.cp - p.sl-ap - p.sl-tcp - cp -
cp - ..... - cp - p.sl-tcp - p.sl-ap - p.cp / 
	                                             |
|

	> In the protection case, if one of the LSPs is being re-groomed
it may have yet another LSP.  I may re-groom the working LSP to a new
working LSP; bridge-and-roll; and teardown the old working LSP.  
	 
	I assume that re-grooming means that the LSP is following a
different path through the network, but keeping the same endpoints? Is
this correct?
	If correct, then re-grooming does not add a new LSP, it simply
changes to path through the network of the LSP.
	 
	If however the endpoints of the LSP change, e.g. in the
protection case above the new working-PST-LSP ends on a different line
card, then there is a new sublayer trail being created with new sublayer
access points. If the Tunnel is defined between the connection points at
the outside of w.cp and p.cp, then the Tunnel would first be extended
with a 3rd PST-LSP and then the initial working-PST-LSP is removed from
the Tunnel.
	 
	But in this latter case the Tunnel is not between access points
or sublayer access points, but between connection points.

	Regards,
	Maarten

---

From: George Swallow <[email-masked]>
Date: Thu, 22 Apr 2010 16:29:11 -0400

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

---

From: Maarten Vissers <[email-masked]>
Date: Fri, 23 Apr 2010 08:58:03 +0200

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

  _____  

Sent: donderdag 22 april 2010 22:29

Maarten -

...George

George,

Regards,
Maarten

  _____  

Malcomb -

...George

Maarten, 

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

---

From: <[email-masked]>
Date: Fri, 23 Apr 2010 08:52:23 +0100

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
------------------------------------------------------------------

	
|<--- W.PST-LSP tunnel ----------------------
	TT=Trail Termination
|<------------- Prot. LSP subnetwork connection -----------------------

	
|<--- 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

	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

		
		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

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 26 Apr 2010 08:00:21 +0200

Neil,
 
As far as I understand the item, there is a need to identify some entity and
to do this identification with a standardized identifier structure. 
The use of the term "tunnel" in this identifier definition has put me in the
wrong direction initially as I have a specific (and in this case incorrect)
understanding associated with "tunnel". It would be possible to replace the
term "tunnel" by another term in the draft, but this only solves a small
part of the issue.
 
There are for me two items to get clarified:
1) within a functional model, what is the entity or what are the entities
that need an identifier?
2) what is the application that requires this entity or those entities to be
identified with a standardized identifier?
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] 
Sent: vrijdag 23 april 2010 9:52
To: [email-masked]; [email-masked]; [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

  _____  

George,

                                                            /-- w.cp --

 

 

 

 
Regards,
Maarten

---

From: <[email-masked]>
Date: Mon, 26 Apr 2010 10:29:13 +0100

Maarten...I can for sure understand your desire to do this, all I am
saying is that there is no real rigour on what this means in IETF.
 
In IP/cl-ps where this term originated it was either true client/server
layering encaps, or used to 'bypass' sections of topology in the *same
layer network* where routing information was not present...so we
'tunnel' the traffic units that contain addressing information that
cannot be routed  in a specific area of topology through that area to a
node somewhere that hopefully can route them.
 
In co-cs mode layer networks (generally all that GMPLS applies to) the
physics only allows pukka client/server *layering* of *parent
connections*, ie the physics forbids the sublayering that we find in
MPLS (S bit).  Of course, if we are attempting to provide a transport
network function using the co-ps mode as we are in MPLS-TP, then we
should not have sublayering anyway.
 
Your classification issue needs to understand the above.....and the real
problem lies in MPLS sublayering IMO.
 
regards, Neil

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

	Neil,
	 
	As far as I understand the item, there is a need to identify
some entity and to do this identification with a standardized identifier
structure. 
	The use of the term "tunnel" in this identifier definition has
put me in the wrong direction initially as I have a specific (and in
this case incorrect) understanding associated with "tunnel". It would be
possible to replace the term "tunnel" by another term in the draft, but
this only solves a small part of the issue.
	 
	There are for me two items to get clarified:
	1) within a functional model, what is the entity or what are the
entities that need an identifier?
	2) what is the application that requires this entity or those
entities to be identified with a standardized identifier?
	 
	Regards,
	Maarten

[email-masked]

	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]] 

		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 --

	

	

		 
		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 <[email-masked]>
Date: Tue, 27 Apr 2010 13:38:47 -0400

Diego -

> o        PSC is also used as Packet Switching Capable for OSPF-TE

The term is now not used in the document, so I will take it out of the list.

> ·         Section 2
> 
> o        Tunnel I think that here a reference to the actual identifier of the
> quoted entity could help I mean a reference to Section 5

I'm going to rewrite the note.  Maybe able to work in the forward reference
you propose if I can make the text flow.

> not in the scope of MPLS-TP

I'm not trying to rule them out.  Right now I'm trying to get to something
that is useable in an IP-less environment as well as an IP environment.  We
have yet to start serious work on the signaling.  We can add these if we
need them then.

> ·         Section 5
> 
> o        Even if section 2 points to 3209 than the Tunnel Identifier chosen is
> different from what is defined in 3209, Extended Tunnel ID field is missing
> while there are two different Tunnel Num that is not clear how they works.  I
> think here the same convention used in 3209 and in GMPLS signaling would be
> good to avoid to have two or more Tunnel identifiers for MPLS-TP networks
> using GMPLS. 

In section 5.3 I show the mapping to GMPLS.  The extended tunnel-id gets
filled in with the destination address.  You will note that the destination
tunnel number doesn't show up at all.  What I have in mind is that the dest
tunnel number would be carried in a new object with the semantic that this
tunnel "connects-to" a particular tunnel number at the destination.  The
object could be filled in by the source (in which case the destination would
verify and accept or reject) or left empty (in which case the destination
would return its chosen value in the RESV).

> o        Why MPLS-TP tunnels must be associated to a LIH?  Why MPLS-TP tunnels
> need to be configured as FA? Does that imply that in case OSPF-TE is used it
> must advertise MPLS-TP tunnels as FA each time a new tunnel is created?

The IF-ID names the access point to the tunnel.  PWs and LSP can be routed
through the interface (AP if you prefer).  They do not need to be advertised
in OSPF.  

> ·         Section 5.2 I think that sentence "The format of a Tunnel_ID is:"
> should be "The format of a LSP_ID is:" same for the globally unique case.

Yes.  Typo - thanks for pointing it out.

> ·         Section 5.3 addresses some of my above concern about usage of tunnel
> and lsp identifiers even if is not a 1:1 mapping given that the Dst-Tunnel_Num
> is not mapped in GMPLS Tunnel ID

Addressed above.

BR

...George

> This Communication is Confidential. We only send and receive email on the
> basis of the term set out at www.ericsson.com/email_disclaimer
> 
> 
> e.g., the associated unidirectional case? This should be clarified.
> 
>

---

From: George Swallow <[email-masked]>
Date: Tue, 27 Apr 2010 13:51:08 -0400

Sri -

See inline:

On 4/2/10 9:11 AM, "Sriganesh Kini" <[email-masked]> wrote:

> Hi,
> 
> 1) section 5.1 - "At each endpoint a tunnel is uniquely identified by the
> Source Node_ID and a locally assigned tunnel number."

Agree - will make change.

>    b) Useful to clarify the scope of "uniquely identified" before this

Will do my best.

>    C) Should there be a similar identifier at each intermediate node besides

The midpoints need to have this (not a similar) identifier too.  Either
through configuration or through signaling.
 
> 2) Section 5.2 - Does any LSR own the "LSP_num" space? If so pls state that.

In the provisioned case, it would be the provisioning system.  In the
signaled case, the end that initiates the signaling.

...George

---

From: George Swallow <[email-masked]>
Date: Wed, 28 Apr 2010 14:38:21 -0400

Maarten -

The former.

...George