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

[<[e-mail]>]

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

regards, neil 

> -----Original Message-----
> From: Maarten Vissers [mailto:[e-mail]] 
> Sent: 21 April 2010 10:06
> To: Harrison,N,Neil,DKQ7 R; [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [mpls-tp] [mpls] mpls wg last call on 
> draft-ietf-mpls-tp-identifiers-01
> 
> Neil,
> 
> There are three MPLS-TP layer netowrks defined:
> 1) Transport Service layer network
>    (including MS-PWs, Service-LSPs, PST-LSPs)
> 2) Transport Path layer network
>    (including Transport-LSPs, PST-LSPs)
> 3) Section layer network
>    (including Section-LSPs, PST-LSPs).
> 
> Each of those three MPLS-TP layer networks has two types of sub-layers
> defined:
> A) TCM sub-layer with a 1:1 relation (for admin domain monitoring
>    and SNC/S protection switching applications)
> B) TCM sub-layer with a n:1 relation (for some protection switching
> applciations)
> which are supported by PST-LSPs.
> 
> The three layer networks have Access Points, and those APs 
> are identified by means of an Access Point Identifier. 
> 
> The sub-layers have sub-layer Access Points, and those 
> sub-layer APs are identified by means of a sub-layer Access 
> Point Identifier.
> 
> 	[Note - We need to understand what the IETF equivalent 
> of the ITU-T Access Point
>       is... See below the '-----' for my view on this based 
> on a question I received
>       on what the equivalent ITU-T construct would be for an 
> IETF 'interface'.]
> 
> The MPLS-TP data plane does not demarc the boundary between 
> those layer networks or between a layer and its sublayers. 
> This is a clear difference with similar layer/sublayer 
> structures in OTN ODU and Ethernet ETH layers; in those two 
> technologies there is a clear demarcation between layer 
> networks and between the layer network signal and its 
> sublayers. But we have to ask ourselves the question if this 
> would be an issue... Most likely not because of the following:
> 
> Transport Service, Transport Path and Section layer names 
> represent roles in a domain. A Transport-LSP in domain A can 
> be passed through a domain B in which it is considered to be 
> a Service-LSP. Similarly, a Section-LSP in domain A can be 
> passed through a domain B in which it is considered to be a 
> Service-LSP. And it is even possible to have a Section-LSP in 
> domain A which is passed through a domain B as Service-LSP 
> and is then handed of to domain C as a Transport-LSP.
> 
> This role variability is also present in the OTN ODU and 
> Ethernet ETH layers, so there is commonality between those 
> three technologies at this point.
> 
> The implication is that the Access Point in e.g. a MPLS-TP 
> Section layer or Ethernet Virtual Section layer could be 
> connected with an Access Point in a MPLS-TP Transport Path or 
> Ethernet Virtual Path layer. This capability is of course a 
> feature and not a bug, and the implication is that the access 
> point identification scheme should be agnostic to the 
> operational role names of the layer networks in each domain.
> 
> -----------
> 
> I was asked the question what the ITU-T equivalent of the 
> IETF 'interface'
> would be.
> It could be that this equivalent is the 'access point'. The 
> access points demark a trail in a layer network and access 
> points are identified by means of their 'access point 
> identifier (APId)'. If you look at clause 8.6.1 in G.7710 
> http://www.itu.int/rec/T-REC-G.7710-200707-I/en then you find 
> in figure 23 a description of how the APId is used to 
> identify the other reference points (termination connection 
> point, connection point).
> 
> In G.831 http://www.itu.int/rec/T-REC-G.831-200003-I/en you 
> find the following features of the access points:
> ----------
> The features of Access Point Identifiers (APIs) are:
> - each access point identifier must be globally unique in its 
> layer network;
> - where it may be expected that the access point may be 
> required for path set-up across an inter-operator boundary, 
> the access point identifier must be available to other 
> network operators; - the access point identifier should not 
> change while the access point remains in existence; - the 
> access point identifier should be able to identify the 
> country and network operator which is responsible for routing 
> to and from the access point; - the set of all access point 
> identifiers belonging to a single administrative layer 
> network should form a single access point identification 
> scheme; - the scheme of access point identifiers for each 
> administrative layer network can be independent from the 
> scheme in any other administrative layer network.
> 
> The API shall begin with either the country code as defined 
> in ITU-T E.164 (one, two or three numeric characters) or, the 
> three alphabetic character country code as defined in ISO 3166.
> The remainder of the API characters that follow the country 
> code shall be a matter for the organization to whom the 
> country code has been assigned, provided that uniqueness is 
> guaranteed.
> These characters may be any alphanumeric characters as 
> defined in ITU-T T.50 (International Reference Version - 
> 7-bit coded character set for information interchange).
> The alphanumeric character set consists of the characters "a" 
> to "z", "A" to "Z", and "0" to "9".
> In the case where the API uses less than fifteen characters, 
> the API will be padded (extended) with the T.50 "NUL" 
> character to get a fifteen byte character string.
> ------------
> 
> 
> Applying this AP, CP and TCP identification in MPLS-TP you 
> would get the
> following:
> 
> - PW access points demark the PW trail
> - PW termination connection points demark the PW network connection
> 
> - LSP access points demark the LSP trail
> - LSP termination connection points demark the LSP network connection
> 
> A PW trail and network connection are identified (PW_TID, 
> PW_NCID) by means of their PW APId set <PW_APId_1, PW_APId_2> 
> for a p2p PW and <PW_APId_1, PW_APId_2, .., PW_APId_n> for a p2mp PW.
> 
> A LSP trail and network connection are identified (LSP_TID, 
> LSP_NCID) by means of their LSP APId set <LSP_APId_1, 
> LSP_APId_2> for a p2p LSP and <LSP_APId_1, LSP_APId_2, .., 
> LSP_APId_n> for a p2mp LSP.
> 
> 
> - a LSP carries one or more client LSPs and/or PWs and/or VPLSs. 
> The client LSP connection points are identified by means of 
> the LSP APId plus the client_LSP label value. 
> The client PW connection points are identified by means of 
> the LSP APId plus the client_PW label value. 
> The client VPLS (i.e. ETH) flow points are identified by 
> means of the LSP APId plus the client_VPLS (i.e. PW) label value.
> 
> - a PW may carry one or more client LSPs. 
> The client LSP connection points are identified by means of 
> the PW APId plus the client_LSP label value. 
> 
> - a PW may carry one or more client VLANs. 
> The client VLAN (i.e. ETH) flow points are identified by 
> means of the PW APId plus the client_VLAN VLAN ID (VID) or 
> Service instance ID (SID) value. 
> 
> The client connection/flow points demark a client link connection.
> A client_LSP or _VLAN link connection supported by a PW trail 
> is then identified by the PW trail identifier (i.e.
> <PW_APId_1,PW_APId_2(,...,PW_APId_n)> plus the client label 
> or VID/SID value.
> A client_LSP/PW/VPLS link connection supported by a LSP trail 
> is then identified by the LSP trail identifier (i.e.
> <LSP_APId_1,LSP_APId_2(,...,LSP_APId_n)> plus the client LSP 
> or PW label value (LSP__LCID, PW_LCID, VPLS_LCID).
> 
> A PW (or LSP) trail contains of one or more PW (or LSP) link 
> connections with unique identifiers. This implies that one PW 
> (or LSP) trail/network connection identifier is related to a 
> set of PW (or LSP) link connection identifiers; e.g. 
> PW_TID/PW_NCID <=> {PW_LCID_a,PW_LCID_b, ...}
> 
> ------------
> 
> PWs and LSPs represent layer network trails and sublayer 
> network trails in the MPLS-TP Transport Service, Transport 
> Path and Section layer networks. An
> overview:
> 
> Transport Service layer network:
> - MPLS-TP PW trail
> - MPLS-TP service-LSP trail
> [- ETH VPLS connectionless trail]
> - MPLS-TP PST-LSP sublayer trail
> 
> Transport Path layer network:
> - MPLS-TP transport-LSP trail
> - MPLS-TP PST-LSP sublayer trail
> 
> Section layer network:
> - MPLS-TP section-LSP trail
> - MPLS-TP PST-LSP sublayer trail
> 
> Note that the PST-LSP sublayer trails performing a TCM 
> function are dependent on the layer trails. If a layer trail 
> is deleted all associated PST-LSP sublayer trails have to be 
> deleted as well.
> 
> In MPLS-TP these sublayer trails perform a complete 
> encapsulation of the layer trail and/or client-sublayer 
> trail. This is different from sublayer trails in SDH, OTN, 
> ATM and Ethernet networks. In those latter network 
> technologies a sublayer trail just adds an additional level 
> of OAM without further encapsulating the incoming signal. As 
> a consequence in those latter networks the addition or 
> removal of a sublayer does not change the set of link 
> connections in the trail/network connection. In MPLS-TP we 
> have to decide if we follow the same model, or if we consider 
> that the addition of a sublayer (i.e. a PST-LSP) changes the 
> number of link connections in the layer trail/network connection. 
> 
> Regards,
> Maarten
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: woensdag 21 april 2010 9:38
> To: [e-mail]; [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: RE: [mpls-tp] [mpls] mpls wg last call on
> draft-ietf-mpls-tp-identifiers-01
> 
> Maarten...agreed...but there is also a worrying addressing 
> problem in all this IMO that does not seem to be 
> recognised/understood.  In summary, a layer network (any 
> mode/technology, not just co-ps/MPLS-TP
> say) is most essentially characterised by its access point 
> addressing scheme...screw this up on day 1 and it is very 
> hard to change later.
> 
> MPLS originally never had proper addressing allocated to 
> it...largely due to is binding with the cl-ps mode IP layer 
> network it could never be seen as a layer network in its own 
> right (part of the common control-plane flaw - I come back on 
> this later).  Further, each LSP here was a *sublayer* and 
> part of the same hybrid/MPLS/IP layer network.
> Moreover, each LSP (label distribution) signalling type 
> created its own form of addressing for how it wanted to 
> identify its type of access points.
> 
> PWs made the situation significantly worse when they became multi-hop.
> These suddenly jumped from an adaptation role to a full blown 
> layer network in their own right.  So they needed their own 
> addressing scheme (and OAM, LDP signalling, etc),...which is 
> what all the AII stuff is.
> Not a great addressing structure I should add, we should have 
> used v4 or
> v6 but the problem dogging this stuff was that we were still 
> claiming this was all part of the same IP/MPLS layer network 
> => can also read as same instance of routing.....something we 
> should know now is a flawed notion for MPLS-T based on 
> lessons learnt from GMPLS (I originally pointed this 'common 
> CP nonsense' out at 2000 San Diego IETF mtg).
> 
> Now MPLS-TP is supposed to be a transport network.  So each 
> LSP in a nested case should be in its own layer 
> network....this is essentially what you shown below.  MPLS-TP 
> therefore does not need sublayering as per the old type of 
> MPLS...and it for sure should not be generating a PW layer 
> network, that simply indicates a failure to deliver a 
> transport network and just propagates the error made in MPLS.
> 
> However, because some folks want to retain the S bit notion 
> and the old type of sublayering in MPLS-TP, we have no way of 
> knowing whether a set of nested LSPs belong to different 
> layer networks or are sublayers in some arbitary layer 
> network grouping.  The DP looks the same in all cases.
> 
> I can see all sorts of problems brewing here in correctly 
> identify which layer network a given LSP belongs to...esp if 
> there are multiple parties involved in both client/server and 
> peer-partition sense. 
> 
> regards, Neil   
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Maarten Vissers
> > Sent: 21 April 2010 08:11
> > To: 'George Swallow'; [e-mail]; [e-mail]; 
> [e-mail]; 
> > [e-mail]
> > Subject: Re: [mpls-tp] [mpls] mpls wg last call on
> > draft-ietf-mpls-tp-identifiers-01
> > 
> > George,
> > 
> > It is a bad practice to identify a connection (e.g. LSP) within the 
> > scope of their server layer trail (e.g. tunnel LSP). Reason 
> is that a 
> > connection (e.g. LSP) is typically carried by multiple server layer 
> > trails (e.g. tunnel LSPs).
> > Example: a service-LSP X is carried over three transport-LSPs A,B,C:
> > 
> >    |<----------------service-LSP_X------------------->|
> >     |<--tr-LSP_A-->| |<--tr-LSP_B-->| |<--tr-LSP_C-->|
> > 
> > It is possible to reroute this service-LSP and change it as follows:
> > 
> >    |<----------------service-LSP_X------------------->|
> >     |<--tr-LSP_A-->| |<-----------tr-LSP_D---------->|
> > 
> > or as follows:
> > 
> >    |<----------------service-LSP_X------------------->|
> >     |<--tr-LSP_A-->| |<--tr-LSP_E-->| |<--tr-LSP_F-->|
> > 
> > The service-LSP X is still the same service-LSP with the same 
> > service-LSP MEP functions, only the path through the 
> MPLS-TP network 
> > has been changed.
> > 
> > Identification with respect to the server layer trail (e.g. 
> > tunnel LSP) is appropriate for a link connection (e.g. LSP 
> segment). 
> > The service-LSP X has three service-LSP segments.
> > Those segments are identified with respect to their tunnel; 
> i.e. with 
> > respect to the transport-LSP in this example.
> > 
> > Regards,
> > Maarten
> > 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of George Swallow
> > Sent: vrijdag 16 april 2010 18:45
> > To: Attila Takacs; Loa Andersson; [e-mail]; [e-mail]; 
> > [e-mail]; [e-mail]
> > Subject: Re: [mpls-tp] [mpls] mpls wg last call on
> > draft-ietf-mpls-tp-identifiers-01
> > 
> > 
> > 
> > 
> > On 4/2/10 2:53 AM, "Attila Takacs" 
> <[e-mail]> wrote:
> > 
> > > Hi Matthew and George,
> > > 
> > > Please find some comments/questions below.
> > > 
> > > -In Section 5.1 you have:
> > > 
> > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num
> > > 
> > > What is the reason of having a Dst-Tunnel_Num besides the
> > Src-Tunnel_Num?
> > 
> > Existing implementations of RSVP-TE have used the tunnel space as 
> > global to the node.  It is difficult if not impossible to 
> coordinate 
> > such spaces between nodes.  In RSVP-TE the coordination does not 
> > matter, since the tail end of the tunnel doesn't have a 
> real interface
> > - it only receives and usually with a PHP of the tunnel 
> label, so the 
> > packets only belong to the physical interface.
> > 
> > In a bidirectional world, separate tunnel spaces at the two ends 
> > becomes useful.
> > 
> > If this independence is not need is some environments then one can 
> > configure just one value and use it in both fields.
> > 
> > > Is it there to support associated unidirectional
> > Tunnels/LSPs? If so
> > > it should be called out in the text.
> > 
> > That was not my original intent, but you are quite correct 
> that this 
> > would be very useful.  Particularly if the associated tunnels pass 
> > through a share mid-point somewhere along the path.
> > 
> > > Same applies to the globally unique case.
> > 
> > Of course.
> > 
> > > -In Section 5.2 you simply append one LSP_Num to the above. 
> > This is a
> > > bit confusing to me, if there are Src/Dst Tunnel_Nums then two 
> > > LSP_Nums would be needed too, wouldn't it?
> > 
> > Once, you have independent tunnel-ids, coordination of the 
> LSP numbers 
> > becomes easy.  It also could be used to allow the two ends 
> to readily 
> > identify which is working and which is protection.
> > 
> > > -In Section 5.3 Mapping to GMPLS signaling does not use the 
> > > Dst-Tunnel_Num. So this means that we may have two
> > different tunnels
> > > identified with
> > > Src-Node_ID::Src-Tunnel_Num::Dst-Node_ID::Dst-Tunnel_Num. Is this
> > intentional, e.g., the associated unidirectional case?
> > 
> > For the associated unidirectional, this works perfectly.  For 
> > bidirectional, I was thinking of two options.
> > 
> > 1)  Strict binding  -  both ends are configure with the full 
> > identifier and will only accept the connection if 
> everything matches.
> > 
> > 2)  Dynamic binding - Source signals with just its 
> Tunnel_Num.  RESV 
> > message would carry back the destination's tunnel_num.  
> Note that both 
> > ends need both pieces for some of the OAM to work.
> > 
> > > This should be clarified.
> > 
> > I'll see what I can do.  But this is not supposed to the MPLS-TP 
> > signaling draft.
> >  
> > > Hmm, maybe the Dst-Tunnel_Num should be omitted altogether.
> > 
> > I'm planning to keep it.
> >  
> > > -Section 7 has a note saying to be aligned with the OAM
> > fwk, is this
> > > still to be done?
> > 
> > Yes.  That draft is also being updated.  We appear to be converging.
> > 
> > > -In section 7.1.2.1 there is a discussion on Tunnel MEG IDs.
> > > How would Tunnel and LSP MEGs be used? What OAM would run at the 
> > > Tunnel level and not at the LSP level?
> > >
> > > Do we need Tunnel MEG_IDs as defined in 7.1.2.1?
> > 
> > I had been told early on that MEGs were needed for tunnels.  
> > Now getting comments that they are not (same comment is in the ITU 
> > liaison).  So I planning to remove it, unless I hear other opinions.
> > 
> > > -Section 7.1.2.2, the Dst-Tunnel_Num question applies here too.
> > 
> > See above.
> > 
> > > -Section 8 talks about open issues? When will these be addressed?
> > 
> > Before it is re-issued.  Goal is end of next week.
> > 
> > ...George
> > 
> > > Thanks,
> > > Attila
> > 
> > _______________________________________________
> > mpls-tp mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> > 
> 
>