Subject: Re: [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: 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.
> 
> 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.
> 
> 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.
>  
> 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 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: 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