Subject: Re: [mpls-tp] Doesn't Occam's Razor apply to networking? (was: Comment on draft-ietf-mpls-tp-framework-08)

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Feb 2010 14:07:42 +0200

Adrian and all,
Please look at the following fragment in Maarten's original message:

<quote>
        Besides specifying those different signal types (comparable with PW, service
        LSP, segment LSP, edge-to-edge LSP, PST LSP, etc), OAM and TCM there is also
        a very clear description of the layers those signal types (including OAM/TCM) are
        a member of. This latter is missing in the MPLS-TP framework document, and this
        will impact the development of network management and the required "operational simplicity"
<end quote>

My reading of this statement (FWIW) is that, from Maarten's point of view MPLS-TP architecture must
follow the guidelines describing the data plane of SONET/SDH even if this results in introduction of artificial
constructs (like segment LSPs) which are nor related to the MPLS reality. If not, the objectives of MPLS-TP
will not be achieved.

So I doubt if this is just a matter of using - or not using some fancy names.

Regards,
        Sasha

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: Sunday, January 31, 2010 10:17 PM
> To: Alexander Vainshtein; Maarten Vissers; 'BOCCI Matthew';
> [email-masked]
> Cc: [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mpls-tp] Doesn't Occam's Razor apply to
> networking? (was: Comment on draft-ietf-mpls-tp-framework-08)
>
> All,
>
> Notwithstanding names, we do seem to have produced several
> components of the
> MPLS-TP architecture. These might be named:
>
> client traffic
> pseudowires*
> LSPs
> server links
>
>
> * Let us please leave to a separate discussion the question
> of whether PW
> should continue to be part of the MPLS-TP world
>
> I see no reason why Maarten should not observe that there is a
> correspondence between these items and other named items in
> other networking
> models. Providing this mapping may be useful to people attempting to
> understand MPLS-TP coming to the scene from elsewhere. Maybe
> representing
> this language in the Rosetta draft would be helpful to these people.
>
> However, I agree with Sasha that there is no value to
> introducing these
> terms to the rest of the MPLS-TP document set. We do not need
> more terms for
> the same things.
>
> Adrian
> ----- Original Message -----
> From: "Alexander Vainshtein" <[email-masked]>
> To: "Maarten Vissers" <[email-masked]>; "'BOCCI Matthew'"
> <[email-masked]>; [email-masked]
> Cc: <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Sent: Sunday, January 31, 2010 7:27 PM
> Subject: [mpls-tp] Doesn't Occam's Razor apply to networking?
> (was: Comment
> on draft-ietf-mpls-tp-framework-08)
>
>
> > Maarten, Matthew and all,
> > A short comment if you do not mind:
> >
> > Maarten,
> > You've stated that:
> >> The functional architectures specified by SG15 are based on the
> >> specification signal structures and functional
> >> specifications of the same
> >> for layer networks as identified for MPLS-TP:
> >> - LO or VC layer networks are transport service layer networks
> >> - HO or VP layer networks are transport path layer networks
> >> - Section layer networks
> >> - Physical media layer networks
> >
> > To the best of my recollection, none of the MPLS-TP
> documents now in
> > progress
> > use/define the terms like LO/VC or HO/VP. IMHO and FWIW,
> this is because
> > these notions, which are quite real in the SONET/SDH data
> plane, do not
> > have any
> > meaning whatsoever in MPLS (TP or not) one, i.e., no data
> plane reality
> > stands behind them.
> >
> > Scientists and engineers have been successfully using the
> Occam's Razor
> > principle
> > (entia non sunt multiplicanda praeter necessitatem) for the
> last 600
> > years.
> > I do not see any reason to drop it now.
> >
> > My 2c,
> >     Sasha
> >
> >
> >> -----Original Message-----
> >> From: [email-masked]
> >> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> >> Sent: Sunday, January 31, 2010 9:03 PM
> >> To: 'BOCCI Matthew'; [email-masked]
> >> Cc: [email-masked]; [email-masked];
> >> [email-masked]
> >> Subject: Re: [mpls-tp] Comment on draft-ietf-mpls-tp-framework-08
> >>
> >> Hi Matthew,
> >>
> >> You state in response of my comment #5 "As is common in the
> >> IETF, we are
> >> describing a functional architecture, not a physical one.".
> >> Description of a
> >> functional architecture is also the approach used by SG15 to
> >> specify its
> >> transport networks.
> >>
> >> The functional architectures specified by SG15 are based on the
> >> specification signal structures and functional
> >> specicifications of the same
> >> for layer networks as identified for MPLS-TP:
> >> - LO or VC layer networks are transport service layer networks
> >> - HO or VP layer networks are transport path layer networks
> >> - Section layer networks
> >> - Physical media layer networks.
> >> For SDH this has resulted in the specification of a series of
> >> LOVC signal
> >> types, their OAM/TCM and their atomic functions (LO VC-11,
> >> VC-12, VC-3), of
> >> HOVC signal types, their OAM/TCM and their atomic functions
> >> (HO VC-3, VC-4,
> >> VC-4-Xc (X=4,16,64,256) and of Section signal types, their
> >> OAM and atomic
> >> functions (RSn, MSn (n=0,1,4,16,64,256).
> >> For OTN this has resulted in the specification of a series of
> >> LO ODU signal
> >> types, their OAM/TCM and atomic functions (LO ODU0, ODU1,
> >> ODU2, ODU2e, ODU3,
> >> ODU4, ODUflex) and of HO ODU signal types, their OAM/TCM and atomic
> >> functions (HO ODU1, ODU2, ODU3, ODU4).
> >> For ATM this has resulted in the specification of a generic
> >> VC signal type,
> >> its OAM/TCM and atomic functions, and of a generic VP
> signal type, its
> >> OAM/TCM and atomic functions.
> >>
> >> Besides specifying those different signal types (comparable
> >> with PW, service
> >> LSP, segment LSP, edge-to-edge LSP, PST LSP, etc), OAM and
> >> TCM there is also
> >> a very clear description of the layers those signal types
> (including
> >> OAM/TCM) are a member of. This latter is missing in the
> >> MPLS-TP framework
> >> document, and this will impact the development of network
> >> management and the
> >> required "operational simplicity" referred to in RFC5654:
> >>    "To realize these goals, it
> >>    is essential that packet-transport technology be
> available that can
> >>    support the same high benchmarks for reliability and operational
> >>    simplicity set by SDH/SONET and OTN technologies."
> >>
> >> When we developped SDH we also developed Rec. G.782. This
> >> recommendation
> >> described a number of SDH equipment types and provided
> >> guidance to realize
> >> SDH networks, without standardizing one physical
> >> architecture. The node
> >> names introduced in that recommendation are still used as
> >> general type names
> >> for SDH functionality combinations.
> >>
> >> To obtain in MPLS-TP netowrks the "operational simplicity set
> >> by SDH/SONET
> >> and OTN technologies." it is in my opinion important to
> complement the
> >> existing specifications in the framework document by an
> >> explicit description
> >> of
> >> - which named signals (PW, service LSP, segment LSP,
> >> edge-to-edge LSP, PST
> >> LSP, etc) are member of the transport service, trnasport path
> >> and section
> >> layer netowrks, and
> >> - some generic node names that reflect the basic
> >> functionality provided by a
> >> common set of MPLS-TP nodes.
> >>
> >> The correspondence in the mpls-tp mailinglist shows that
> >> there is no common
> >> understanding of the set of labelled signals specified in
> the MPLS-TP
> >> framework draft and the layers those signals belong to. It is
> >> as such more
> >> then necessary to include a listing - in an additional
> section in the
> >> framework document - of the MPLS-TP layers and their labelled
> >> signals. A
> >> table would be a great help for readers to combine labelled
> >> signal types and
> >> their layers. Any new labelled signal types introduced in
> future (e.g.
> >> packet PW) can be simply added to the appropriate layer.
> >>
> >> -------
> >>
> >> REQ30 in RFC5654 requires
> >>       "A generic and extensible solution MUST be provided to
> >> support the
> >>        transport of one or more client layer networks
> (e.g., MPLS-TP,
> >>        IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP
> >> layer network."
> >>
> >> In order to support p2p/p2mp Ethernet, ATM, FR, etc services this
> >> requirement 30 enforces that PWs must be an integral part of
> >> the MPLS-TP
> >> layer networks, specifically the MPLS-TP transport service layer.
> >> In order to support rmp/mp2mp Ethernet services, this
> requirement 30
> >> enforces that HVPLS instances must be an integral part of the
> >> MPLS-TP layer
> >> netowrks, specifically are a part of the MPLS-TP transport
> >> service layer.
> >> Excluding the PW and HVPLS from MPLS-TP implies that REQ30 is
> >> not met by the
> >> MPLS-TP framework specifications; i.e. MPLS-TP is not just
> about LSPs.
> >>
> >>
> >> My conclusion is therefore that the MPLS-TP framework
> >> document is currently
> >> not complete and does not meet all requirements in RFC5654.
> >>
> >> Regards,
> >> Maarten
> >>
> >>
> >> -----Original Message-----
> >> From: BOCCI Matthew [mailto:[email-masked]]
> >> Sent: donderdag 28 januari 2010 16:03
> >> To: Maarten Vissers; [email-masked]
> >> Cc: [email-masked];
> >> [email-masked];
> >> [email-masked]
> >> Subject: RE: Comment on draft-ietf-mpls-tp-framework-08
> >>
> >> Hi Maarten,
> >>
> >> Thanks for your comments.
> >>
> >> Please see below.
> >>
> >> > -----Original Message-----
> >> > From: Maarten Vissers [mailto:[email-masked]]
> >> > Sent: 27 January 2010 16:53
> >> > To: [email-masked]; BOCCI Matthew
> >> > Cc: [email-masked];
> >> > [email-masked]; [email-masked]
> >> > Subject: Comment on draft-ietf-mpls-tp-framework-08
> >> >
> >> >
> >> >
> >> > Below a number of issues identified in
> >> > draft-ietf-mpls-tp-framework-08 which requires further
> >> enhancements to
> >> > the framework draft:
> >> >
> >> > 1. Section 3.3.2 - the 6th paragraph states:
> >> >    'Further processing to determine the context of a
> packet occurs
> >> > when a
> >> >    swap operation is interrupted in this manner, or a
> pop operation
> >> >    exposes a specific reserved label at the top of the stack.
> >> >  Otherwise
> >> >    the packet is forwarded according to the procedures in
> >> [RFC3032].'
> >> >
> >> >     A Section layer LSP is typically carried over the
> >> physical media
> >> > layer
> >> >     in an unlabelled manner; i.e. as an 'unlabelled LSP'.
> >> > The Section LSP OAM
> >> >     packets will have as top of stack label the GAL.
> >> > Packets received by
> >> >     an input port with the GAL as top label will have to be
> >> "further
> >> > processed
> >> >     to determine the context of the packet"; such
> packets are to be
> >> > exposed
> >> >     to this further processing wihtout an interruption of a swap
> >> > operation,
> >> >     and without a pop operation exposing a reserved label.
> >> > It is suggested
> >> >     to describe that further processing is also occuring on
> >> packets with
> >> >     GAL as top of stack label.
> >>
> >> OK. We will add text to explain this point.
> >>
> >>
> >> >
> >> > 2.  Section 3.4.3, page 23, 3rd paragraph states:
> >> >    'Service labels are typically carried over an MPLS-TP LSP
> >> > edge-to-edge
> >> >    (or transport path layer). An MPLS-TP edge-to-edge LSP is
> >> >    represented as an LSP Demux label as shown in Figure 10.
> >> > An edge-to-
> >> >    edge LSP is commonly used when more than one service
> >> exists between
> >> >    two PEs.'
> >> >
> >> >     Is it possible to formally define the term
> "edge-to-edge LSP"?
> >> >     E.g. An edge-to-edge LSP is a LSP within the transport
> >> path layer
> >> >     which carries an aggregate of transport service layer signals
> >> >     from a PE node via zero or more P nodes to the next PE node.
> >>
> >> OK. Added clarification to where we first use the term.
> >>
> >> >      'The edge-to-edge LSP may be omitted when only one service
> >> >    exists between two PEs.  For example, if only one service is
> >> > carried
> >> >    between two PEs then a single Service Label could be used to
> >> > provide
> >> >    both the service indication and the MPLS-TP edge-to-edge LSP.'
> >> >
> >>
> >> OK. We will add a definition where it is first used.
> >>
> >> >     Edge-to-edge LSPs are typically set up prior to the
> >> first service
> >> >     request. Edge-to-edge LSPs are as such part of the
> >> infrastrcuture
> >> >     of the MPLS-TP network, specifically of the MPLS-TP domain
> >> >     bounded by a set of PE nodes.
> >> >
> >> >     It seems as such not correct to state that if one
> >> service is carried
> >> >     between two Pes that the edge-to-edge LSP label can
> be removed.
> >> >     It should be expected that a next service request
> will add a 2nd
> >> >     transport service layer signal to the edge-to-edge LSP.
> >> >
> >>
> >> Yes, but it explicitly says that if there is only one
> >> service. This is not
> >> mandatory, though. If you are intending to add new LSPs, then
> >> set the first
> >> one up in an edge-to-edge LSP. The way to add another service
> >> would be to
> >> move the service LSP onto an edge-to-edge LSP. I suggest that
> >> we address
> >> this in the same manner as agreed on the editing call so that
> >> we turn this
> >> text on what is essentially an optimisation into a note (as per the
> >> encapsulation label case).
> >>
> >> >     In addition, edge-to-edge LSPs are multiplexed into
> the Section
> >> >     layer transport path, and if the edge-to-edge LSP label
> >> stack entry
> >> >     header would be removed, then it is not longer possible
> >> to identify
> >> >     the existence of the edge-to-edge LSP.
> >> >
> >> >     Only when the edge-to-edge LSP would be the only
> >> edge-to-edge LSP
> >> >     on a physical media, then it is possible to carry the
> >> edge-to-edge
> >> >     LSP as an unlabelled-LSP.
> >> >     Note that there will in this case be no need for a
> >> Section layer.
> >>
> >> I don't think the text implies that you use an unlabelled LSP
> >> or implicit
> >> null LSP label. It merely says that there is only a service
> >> LSP, and that
> >> spans edge-to-edge.
> >>
> >> >
> >> > 3. Section 3.6, Figure 12: The figure mentions that "service"
> >> > is transported
> >> >     over the ACH/GAL. This is not aligned with the text. It
> >> is suggested
> >> >     to replace this by "FCAPS".
> >> >
> >>
> >> OK.
> >>
> >> > 4. Section 3.7.1 introduces the terms
> >> >     "end-to-end LSP", "segment LSP" without defining those
> >> terms. Please
> >> >     add explicit definitions of those new terms to the
> framework and
> >> >     describe the relation with the "edge-to-edge LSP" and
> >> "service LSP".
> >> >
> >>
> >> End-to-end LSP should really be edge-to-edge. We will add
> >> definitions in the
> >> terminology.
> >>
> >>
> >> > 5. The terms "T-PE", "S-PE", "MPLS-TP PE", "MPLS-TP P",
> >> "MPLS-TP LSR"
> >> > and
> >> >     "MPLS-TP LER" are described or defined in the
> >> Terminology section
> >> > 1.3
> >> >     and subsections.
> >> >     - In section 1.3.5 a description of the term "MPLS-TP LER" is
> >> > missing;
> >> >       it is suggested to add such description.
> >>
> >> OK. We'll add a definition.
> >>
> >> >     - In Section 1.3.5 it is stated that:
> >> >    'The terms MPLS-TP PE router and MPLS-TP P router
> >> >    describe logical functions; a specific node may
> >> undertake only one
> >> > of
> >> >    these roles on a given LSP.'
> >> >       The above implies that the terms PE and P can not be
> >> used as node
> >> >       names. Each MPLS-TP node will be providing P
> >> functionality for one
> >> >       LSP and PE functionality for another LSP; e.g.
> when a MEP is
> >> > present
> >> >       to support the monitoring of a transport path segment, a PE
> >> > function
> >> >       is performed by such MEP, nonetheless that the
> >> transport path is
> >> >       continued (P function).
> >> >       My request is to introduce terminology for MPLS-TP
> >> nodes, which
> >> >       is based on the MPLS-TP layer (transport service
> >> layer, transport
> >> >       path layer, section layer) processing.
> >> >
> >>
> >> As is common in the IETF, we are describing a functional
> >> architecture, not a
> >> physical one. Therefore it is appropriate to focus on the
> >> logical aspects of
> >> the network, and thus the terminology is tailored to this style of
> >> specification. That does not preclude a mapping of logical
> >> functions to
> >> physical nodes being defied elsewhere, with the appripriate
> >> terminology, but
> >> it is not the objective of this framework draft.
> >>
> >>
> >> >       "Transport Service layer Terminating" node is a
> node in which
> >> >       the transport service layer transport paths are
> >> terminated and the
> >> >       customer signal is accessed. This node is the
> >> start/endpoint of
> >> PW,
> >> >       Service LSP and LSP transport service layer transport
> >> paths. This
> >> >       node may also be the start/endpoint of one or more
> >> additional MEG
> >> >       levels - monitoring a carrier segment or a protection
> >> segment -
> >> >       within a transport service layer transport path.
> This node may
> >> also
> >> >       be the start/endpoint of one or more transport path layer
> >> transport
> >> >       paths.
> >> >
> >> >       "Transport Service layer Switching" node is a node in
> >> which the
> >> >       transport service layer transport paths (PW, service
> >> LSP, LSP,..)
> >> > are
> >> >       switched. This node may also be the start/endpoint of
> >> one or more
> >> >       additional MEG levels - monitoring a carrier segment or a
> >> > protection
> >> >       segment - within a transport service layer transport
> >> path. This
> >> > node
> >> >       may also be the start/endpoint of one or more
> >> transport path layer
> >> >       transport paths.
> >> >
> >> >       "Transport Path layer Switching" node is a node in
> which the
> >> > transport
> >> >       path layer transport paths (edge-to-edge LSPs, ...)
> >> are switched.
> >> > This
> >> >       node may also be the start/endpoint of one or more
> >> additional MEG
> >> > levels
> >> >       - monitoring a carrier segment or a protection
> >> segment - within a
> >> >       transport path layer transport path.
> >> >
> >>
> >>
> >>
> >> > 6. It is requested to describe the relationship between the
> >> different
> >> > label
> >> >     stack entry headers defined in this framework and
> the transport
> >> > service
> >> >     layer, transport path layer and section layer. The
> >> transport service
> >> >
> >> >     layer transport path signals may be identified by a
> >> variety of label
> >> >     stack entry (LSE) header types; e.g. PW LSE, Encap +
> Service LSP
> >> LSE,
> >> >     LSP LSE, one or more Segment LSP LSEs (supporting an
> >> additional MEG
> >> > level
> >> >     within the transport path), PST LSE. The transport path layer
> >> > transport
> >> >     path signals may be identified by a variety of LSE
> header types;
> >> e.g.
> >> >     edge-to-edge LSP LSE, one or more segment LSP LSEs, PST
> >> LSE. The
> >> > section
> >> >     layer transport path signals may be unlabelled, or
> >> labelled (when
> >> >     carried over a section layer segment LSP).
> >>
> >>
> >> I do not think this mapping is needed in this draft, but
> that does not
> >> preclude this mapping being described in an ITU document.
> >>
> >> >
> >> > 7. On the mpls-tp mailinglist a bundling application was
> >> described in
> >> > which
> >> >     e.g. four TDM PWs were bundled into a single bundle LSP at a
> >> > transport
> >> >     service layer terminating node and then transported
> through as a
> >> >     transport service layer transport path through the
> >> MPLS-TP network
> >> to
> >> >     the far end transport service layer terminating node.
> >> > It is proposed to
> >> >     introduce such bundle LSP as one of the transport
> service layer
> >> >     transport path alternatives, and define if it is necessary to
> >> monitor
> >> >     the individual PWs, or if it is sufficient to
> monitor the bundle
> >> LSP.
> >>
> >> There was an informal discussion and an I-D a while ago in
> >> PWE3 on something
> >> similar, but nothing was progressed. There is nothing in
> MPLS-TP that
> >> prevents it, but I don't think it is approriate to define it here.
> >> Such a concept would need to be formally defined in PWE3.
> >>
> >>
> >> >
> >> > 8. Section 3.8: The trnasport service layer contains
> >> > transport paths with
> >> >     a variety of label stack entry headers (PW, service
> >> > LSP, LSP, segment
> >> >     LSP, PST LSP), which requires that the transport
> >> > service layer of which
> >> >     the PWs have to be controlled by LDP and the LSPs by GMPLS. A
> >> >     single transport service layer transport path may as
> >> > such have parts that
> >> >     require LDP and other parts that require GMPLS based
> >> > control to be
> >> >     setup. The activation of e.g. an additional MEG level
> >> > in a PW type
> >> >     transport service layer transport path will require
> >> > that some of the
> >> >     transport service layer transport path is not longer be
> >> > controlled by
> >> >     LDP, but instead by GMPLS. It seems that this is
> >> > introducing unnecessary
> >> >     complexity in the transport service layer, and it is
> >> > proposed to select
> >> >     a single control plane type for all transport paths in
> >> > the transport
> >> >     service layer.
> >>
> >> I think this echos the sentiment in the informal comments
> >> from the ITU.
> >> These were discussed on the call
> >> on Tuesday 26th Jan, and we have addressed this with a note that
> >> although T-LDP is currently used for PWs,
> >> MPLS-TP does not preclude the future definition of
> alternative control
> >> protocols for PWs.
> >>
> >> Regards
> >>
> >> Matthew
> >>
> >>
> >> >
> >> > Regards,
> >> > Maarten
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>
> >> _______________________________________________
> >> mpls-tp mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/mpls-tp
> >>
> > _______________________________________________
> > mpls-tp mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mpls-tp
> >
>
>

---

From: <[email-masked]>
Date: Mon, 1 Feb 2010 12:38:43 -0000

The key observation in all this is that cl-ps mode != co-ps mode !=
co-cs mode.  If each mode was 'the same' then IETF would never have need
bothered with MPLS and GMPLS, and we could just do it all in IP.

It is the *differences* in the modes that are the key points.  They
cannot be made look identical...but if we assume they could for one
moment, then we can apply Occam's razor and dump all technologies bar
one.  At least that way we avoid the costs of having multiple
technologies and (even worse) having to interwork them as peers!

Having said that, we can *sensibly* re-use some of the DP/CP/MP
components in each of the 3 modes. 

regards, neil

> [mailto:[email-masked]] On Behalf Of Alexander Vainshtein
> Sent: 01 February 2010 12:08
> To: Adrian Farrel
> Cc: Matthew'; [email-masked]; 
> [email-masked]; [email-masked]
> My reading of this statement (FWIW) is that, from Maarten's 
> point of view MPLS-TP architecture must follow the guidelines 
> describing the data plane of SONET/SDH even if this results 
> in introduction of artificial constructs (like segment LSPs) 
> which are nor related to the MPLS reality. If not, the 
> objectives of MPLS-TP will not be achieved.
> 
> > Subject: Re: [mpls-tp] Doesn't Occam's Razor apply to networking? 
> > (was: Comment on draft-ietf-mpls-tp-framework-08)
> >
> > All,
> >
> components 
> > of the MPLS-TP architecture. These might be named:
> >
> > client traffic
> > pseudowires*
> > LSPs
> > server links
> >
> >
> of whether 
> > PW should continue to be part of the MPLS-TP world
> >
> > correspondence between these items and other named items in other 
> > networking models. Providing this mapping may be useful to people 
> > attempting to understand MPLS-TP coming to the scene from 
> elsewhere. 
> > Maybe representing this language in the Rosetta draft would 
> be helpful 
> > to these people.
> >
> > However, I agree with Sasha that there is no value to introducing 
> > these terms to the rest of the MPLS-TP document set. We do not need 
> > more terms for the same things.
> >
> > Adrian
> > >> specification signal structures and functional specifications of 
> > >> the same for layer networks as identified for MPLS-TP:
> > >> You state in response of my comment #5 "As is common in 
> the IETF, 
> > >> we are describing a functional architecture, not a 
> physical one.".
> > >> Description of a
> > >> specify its transport networks.
> > >>
> specicifications of 
> > >> the same for layer networks as identified for MPLS-TP:
> > >> For SDH this has resulted in the specification of a 
> series of LOVC 
> > >> signal types, their OAM/TCM and their atomic functions 
> (LO VC-11, 
> > >> VC-12, VC-3), of HOVC signal types, their OAM/TCM and 
> their atomic 
> > >> functions (HO VC-3, VC-4, VC-4-Xc (X=4,16,64,256) and of Section 
> > >> signal types, their OAM and atomic functions (RSn, MSn 
> > >> (n=0,1,4,16,64,256).
> > >> For OTN this has resulted in the specification of a series of LO 
> > >> ODU signal types, their OAM/TCM and atomic functions (LO ODU0, 
> > >> ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex) and of HO ODU 
> signal types, 
> > >> their OAM/TCM and atomic functions (HO ODU1, ODU2, ODU3, ODU4).
> > >> For ATM this has resulted in the specification of a generic VC 
> > >> signal type, its OAM/TCM and atomic functions, and of a 
> generic VP
> > signal type, its
> > >> Besides specifying those different signal types (comparable with 
> > >> PW, service LSP, segment LSP, edge-to-edge LSP, PST LSP, 
> etc), OAM 
> > >> and TCM there is also a very clear description of the 
> layers those 
> > >> signal types
> > (including
> > >> OAM/TCM) are a member of. This latter is missing in the MPLS-TP 
> > >> framework document, and this will impact the development 
> of network 
> > >> management and the required "operational simplicity" 
> referred to in 
> > >> RFC5654:
> > >> recommendation described a number of SDH equipment types and 
> > >> provided guidance to realize SDH networks, without standardizing 
> > >> one physical architecture. The node names introduced in that 
> > >> recommendation are still used as general type names for SDH 
> > >> functionality combinations.
> > >>
> > >> To obtain in MPLS-TP netowrks the "operational simplicity set by 
> > >> SDH/SONET and OTN technologies." it is in my opinion important to
> > complement the
> > >> existing specifications in the framework document by an explicit 
> > >> description of
> > >> LSP, PST LSP, etc) are member of the transport service, 
> trnasport 
> > >> path and section layer netowrks, and
> > >> - some generic node names that reflect the basic functionality 
> > >> provided by a common set of MPLS-TP nodes.
> > >>
> there is 
> > >> no common understanding of the set of labelled signals 
> specified in
> > the MPLS-TP
> > >> framework draft and the layers those signals belong to. It is as 
> > >> such more then necessary to include a listing - in an additional
> > section in the
> > >> signals. A table would be a great help for readers to combine 
> > >> labelled signal types and their layers. Any new labelled signal 
> > >> types introduced in
> > future (e.g.
> > >>        IP, MPLS, Ethernet, ATM, FR, etc.) over an MPLS-TP layer 
> > >> network."
> > >>
> > >> requirement 30 enforces that PWs must be an integral part of the 
> > >> MPLS-TP layer networks, specifically the MPLS-TP 
> transport service 
> > >> layer.
> > >> MPLS-TP layer netowrks, specifically are a part of the MPLS-TP 
> > >> transport service layer.
> > >> Excluding the PW and HVPLS from MPLS-TP implies that 
> REQ30 is not 
> > >> met by the MPLS-TP framework specifications; i.e. MPLS-TP is not 
> > >> just
> > about LSPs.
> > >>
> > >>
> document is 
> > >> currently not complete and does not meet all requirements in 
> > >> RFC5654.
> > >>
> > >> Regards,
> > >> Maarten
> > >>
> > >>
> service. This 
> > >> is not mandatory, though. If you are intending to add new LSPs, 
> > >> then set the first one up in an edge-to-edge LSP. The way to add 
> > >> another service would be to move the service LSP onto an 
> > >> edge-to-edge LSP. I suggest that we address this in the 
> same manner 
> > >> as agreed on the editing call so that we turn this text 
> on what is 
> > >> essentially an optimisation into a note (as per the 
> encapsulation 
> > >> label case).
> > >>
> > >> I don't think the text implies that you use an unlabelled LSP or 
> > >> implicit null LSP label. It merely says that there is only a 
> > >> service LSP, and that spans edge-to-edge.
> > >>
> > >> >
> > >> definitions in the terminology.
> > >>
> > >>
> > >> architecture, not a physical one. Therefore it is appropriate to 
> > >> focus on the logical aspects of the network, and thus the 
> > >> terminology is tailored to this style of specification. 
> That does 
> > >> not preclude a mapping of logical functions to physical 
> nodes being 
> > >> defied elsewhere, with the appripriate terminology, but 
> it is not 
> > >> > 8. Section 3.8: The trnasport service layer contains transport 
> > >> > paths with
> > >> >     a variety of label stack entry headers (PW, 
> service LSP, LSP, 
> > >> > segment
> > >> >     LSP, PST LSP), which requires that the transport service 
> > >> > layer of which
> > >> >     single transport service layer transport path may as such 
> > >> > have parts that
> > >> >     require LDP and other parts that require GMPLS 
> based control 
> > >> > to be
> > >> >     setup. The activation of e.g. an additional MEG 
> level in a PW 
> > >> > type
> > >> >     transport service layer transport path will 
> require that some 
> > >> > of the
> introducing 
> > >> > unnecessary
> > >> >     complexity in the transport service layer, and it 
> is proposed 
> > >> > to select
> > >> >     a single control plane type for all transport paths in the 
> > >> > transport
> > >> >     service layer.
> > >>
> > >> I think this echos the sentiment in the informal 
> comments from the 
> > >> ITU.
> > >> although T-LDP is currently used for PWs, MPLS-TP does 
> not preclude 
> > >> the future definition of
> > alternative control
> > >> protocols for PWs.
> > >>
> > >> Regards
> > >>
> > >> Matthew
> > >>
> > >>
> > >> >
> > >> > Regards,
> > >> > Maarten
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >>

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 01 Feb 2010 15:04:04 +0100

Sasha,

Segment LSPs are the LSPs that implement the TCM function in MPLS-TP.
TandemConnection/Segment Monitoring is not "artificial" as you suggest.
TandemConnections/Segments exist within SDH, ATM, OTN and Ethernet. They are
also defined in MPLS-TP and the identification is performed via label
stacking. Each of the listed technologies has its own method to identify the
TCM/Segment monitoring levels within the frames.

There are different PW and LSP types identified in the framework document
and there are three layers specified in RFC5654. What I request is to
identify which PW/LSP belongs to which layer.

In the framework document there are a few locations in which the
relationship between PW/LSP and layer is mentioned, but this is not done
consistently throughout the document. 

E.g in the text above Figure 8 it is stated that the PW demux label
identifies the transport service layer and the LSP demux label identifies
the transport path layer. 
Similarly in the text below figure 10 it is stated that the transport
service layer is identifeied by the service LSP demux label and the
transport path layer by the LSP demux label.

On page 23 it is stated that "Service labels are typically carried over an
MPLS-TP LSP edge-to-edge
   (or transport path layer).  An MPLS-TP edge-to-edge LSP is
   represented as an LSP Demux label as shown in Figure 10.  An edge-to-
   edge LSP is commonly used when more than one service exists between
   two PEs."
It seems that an edge-to-edge LSP belongs to the transport path layer, and
that such edge-to-edge LSP is used when more then one service exists between
two PEs.

Section 3.7.1 introduces Segment LSPs, but does not list to which layer
these belong. My understanding is that Segment LSPs will be present in the
trnasport service layer (to support TCM function for Service LSPs and PWs),
in the transport path layer (to support TCM function for Edge-to-edge LSP)
and section layer (to support TCM function for Sections). But an
understanding is an interpretation of an ambiguous standard. My request is
to remove this ambiguity and explictly specify in which layers segment LSPs
are applicable. If and when such segment LSPs are deployed is a choice of
the operator.

Section 3.11 introduces PST LSPs, but does not list to which layer these
belong. My understanding is that PST LSPs will be present in the transport
path layer (to support group protection of transport path layer transport
paths (e.g. edge-to-edge LSPs). But an understanding is an interpretation of
an ambiguous standard. My request is to remove this ambiguity and explictly
specify in which layers PST LSPs are applicable. If and when such PST LSPs
are deployed is a choice of the operator.

Regards,
Maarten

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 1 februari 2010 13:08
To: Adrian Farrel
Cc: [email-masked]; [email-masked];
[email-masked]; Maarten Vissers; 'BOCCI Matthew'; [email-masked]
Subject: RE: [mpls-tp] Doesn't Occam's Razor apply to networking? (was:
Comment on draft-ietf-mpls-tp-framework-08)

Adrian and all,

<quote>
        Besides specifying those different signal types (comparable with PW,
service
        LSP, segment LSP, edge-to-edge LSP, PST LSP, etc), OAM and TCM there
is also
        a very clear description of the layers those signal types (including
OAM/TCM) are
        a member of. This latter is missing in the MPLS-TP framework
document, and this
        will impact the development of network management and the required
"operational simplicity"
<end quote>

My reading of this statement (FWIW) is that, from Maarten's point of view
MPLS-TP architecture must follow the guidelines describing the data plane of
SONET/SDH even if this results in introduction of artificial constructs
(like segment LSPs) which are nor related to the MPLS reality. If not, the
objectives of MPLS-TP will not be achieved.

So I doubt if this is just a matter of using - or not using some fancy
names.

Regards,
        Sasha

> Notwithstanding names, we do seem to have produced several components 
> * Let us please leave to a separate discussion the question of whether 
> attempting to understand MPLS-TP coming to the scene from elsewhere. 
> Maybe representing this language in the Rosetta draft would be helpful 
> to these people.
>
> >> You state in response of my comment #5 "As is common in the IETF, 
> >> we are describing a functional architecture, not a physical one.".
> >> Description of a
> >> specification signal structures and functional specicifications of 
> >> For SDH this has resulted in the specification of a series of LOVC 
> >> signal types, their OAM/TCM and their atomic functions (LO VC-11, 
> >> VC-12, VC-3), of HOVC signal types, their OAM/TCM and their atomic 
> >> ODU1, ODU2, ODU2e, ODU3, ODU4, ODUflex) and of HO ODU signal types, 
> >> signal type, its OAM/TCM and atomic functions, and of a generic VP
> signal type, its
> >> PW, service LSP, segment LSP, edge-to-edge LSP, PST LSP, etc), OAM 
> >> and TCM there is also a very clear description of the layers those 
> >> signal types
> (including
> >> framework document, and this will impact the development of network 
> >> management and the required "operational simplicity" referred to in 
> >> RFC5654:
> >> - which named signals (PW, service LSP, segment LSP, edge-to-edge 
> >> LSP, PST LSP, etc) are member of the transport service, trnasport 
> >> The correspondence in the mpls-tp mailinglist shows that there is 
> >> no common understanding of the set of labelled signals specified in
> the MPLS-TP
> >> MPLS-TP layer networks, specifically the MPLS-TP transport service 
> >> layer.
> >> Excluding the PW and HVPLS from MPLS-TP implies that REQ30 is not 
> >> My conclusion is therefore that the MPLS-TP framework document is 
> >> Yes, but it explicitly says that if there is only one service. This 
> >> edge-to-edge LSP. I suggest that we address this in the same manner 
> >> as agreed on the editing call so that we turn this text on what is 
> >> essentially an optimisation into a note (as per the encapsulation 
> >> label case).
> >>
> >> terminology is tailored to this style of specification. That does 
> >> not preclude a mapping of logical functions to physical nodes being 
> >> defied elsewhere, with the appripriate terminology, but it is not 
> >> the objective of this framework draft.
> >>
> >>
> >> >     a variety of label stack entry headers (PW, service LSP, LSP, 
> >> > segment
> >> >     require LDP and other parts that require GMPLS based control 
> >> > to be
> >> >     setup. The activation of e.g. an additional MEG level in a PW 
> >> > type
> >> >     transport service layer transport path will require that some 
> >> > of the
> >> >     LDP, but instead by GMPLS. It seems that this is introducing 
> >> > unnecessary
> >> >     complexity in the transport service layer, and it is proposed 
> >> > to select
> >> I think this echos the sentiment in the informal comments from the 
> >> ITU.
> >> although T-LDP is currently used for PWs, MPLS-TP does not preclude 
> >> the future definition of
> alternative control
> >> protocols for PWs.
> >>
> >> Regards
> >>
> >> Matthew
> >>
> >>
> >> >
> >> > Regards,
> >> > Maarten
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Feb 2010 16:26:55 +0200

Maarten,
Spitting a new thread to deal specifically with "segment LSPs".

To the best of my recollection:
- segments in question are contiguous sequences of nodes and links transited by an LSP
- in order to monitor a segment, you create an entirely new LSP (because it must be terminated
  by the last node of the segment which is, generally speaking, different from the tail-end node
  of the LSP containing this segment)
- as a consequence, there are no hard guarantees that the segment LSP will be indeed fate-sharing
  with the original LSP (in the considered segment). As such, its usefulness for OAM purposes looks
  highly problematic.

As for TCM in other technologies:
- As Neil has stated more than once on this list, SDH and OTN are co-cs, and hence very different from co-ps..
  Hence the validity of referencing them is not clear at best. And, AFAIK, SONET operators somehow do reasonably
  well without TCM...
- Ethernet OAM uses level-bound well-known multicast addresses for addressing MEPs at different levels.
  This  kludge is not applicable to MPLS-TP
- ATM indeed has "segment OAM". However, AFAIK, most (if not all) ATM switches consider physical links as segments
  (do not provide ability to configure segment endpoints). Hence while segments exits in  ATM as described in I-610, their
   existence in real life is a bit problematic.

My bottom line is that "segment LSPs" in MPLS-TP provide a good example of an artificial construct introduced
in order to suit a certain aspect of an abstract model. Usefulness of such a construct in MPLS-TP and of the
specific aspect of the generic model in question (TCM) in other technologies is problematic.

Regards,
     Sasha

> Sent: Monday, February 01, 2010 4:04 PM
> To: Alexander Vainshtein; 'Adrian Farrel'
> [email-masked]; 'BOCCI Matthew'; [email-masked]
> Subject: RE: [mpls-tp] Doesn't Occam's Razor apply to
> point of view

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 01 Feb 2010 15:54:33 +0100

Hi Sasha,

See inline... 

-----Original Message-----
From: Alexander Vainshtein [mailto:[email-masked]] 
Sent: maandag 1 februari 2010 15:27
To: Maarten Vissers
Cc: [email-masked]; [email-masked]; 'BOCCI
Matthew'; [email-masked]; 'Adrian Farrel'
Subject: Segment LSPs (was: [mpls-tp] Doesn't Occam's Razor apply to
networking?)

Maarten,

To the best of my recollection:
- segments in question are contiguous sequences of nodes and links transited
by an LSP
- in order to monitor a segment, you create an entirely new LSP (because it
must be terminated
  by the last node of the segment which is, generally speaking, different
from the tail-end node
  of the LSP containing this segment)
- as a consequence, there are no hard guarantees that the segment LSP will
be indeed fate-sharing
  with the original LSP (in the considered segment). As such, its usefulness
for OAM purposes looks
  highly problematic.

[maarten] The original transport path signal is carried over the Segment
LSP, and by doing this there is a guaranteed fate sharing between the two.
The Segment LSP construct is an implementation of activating an additional
MEG level within the transport path.

[maarten] If the transport path existed prior to the activation of the
additional MEG level in the transport path, it is a requirement that the set
up of the Segment LSP does not change the path through the network of the
original transport path. The two main things that must be done in such case
are:
1) activation and configuration of the MEP functions at the appropriate NNI
or UNI-N ports
2) change the label values identifying the transport path within the Segment
LSP to the new Segment LSP label values.

As for TCM in other technologies:
- As Neil has stated more than once on this list, SDH and OTN are co-cs, and
hence very different from co-ps..
  Hence the validity of referencing them is not clear at best. And, AFAIK,
SONET operators somehow do reasonably
  well without TCM...
- Ethernet OAM uses level-bound well-known multicast addresses for
addressing MEPs at different levels.
  This  kludge is not applicable to MPLS-TP
- ATM indeed has "segment OAM". However, AFAIK, most (if not all) ATM
switches consider physical links as segments
  (do not provide ability to configure segment endpoints). Hence while
segments exits in  ATM as described in I-610, their
   existence in real life is a bit problematic.

[maarten] The functional concept of TCM and its MEG levels is technology
independent and associated to the existence of "transport entities" in
co-cs, co-ps and cl-ps capable technologies.
The encoding of the TCM/MEG level and OAM elements is technology specific. 

[maarten] As I have told you before, Ethernet OAM does not use well-known
multicast addresses to address MEPs at different levels (it doesn't work for
the Y.1731 Ethernet OAM set). Ethernet OAM uses the MEL field to do this.
Please read G.8021. MPLS-TP OAM could have been using an MEG Level (MEL)
field encoding as well, but it was decided to use the label stacking method
to encode MEG Levels.

[maarten] SDH TCM was too late added to the standards, and it took to long
to get it introduced into the networks; this limited its deployment
significantly. ATM TCM/Segment monitoring was introdcued from day one, and
is used in ATM VC connections of which the endpoints are in the customer
domains.

My bottom line is that "segment LSPs" in MPLS-TP provide a good example of
an artificial construct introduced in order to suit a certain aspect of an
abstract model. Usefulness of such a construct in MPLS-TP and of the
specific aspect of the generic model in question (TCM) in other technologies
is problematic.

[maarten] Multi-operator networks and protection switching applications
depend on the support of more then one MEG Level within a transport
path/connection. E.g. 1:1 SNC protection will not work without an additional
TCM/MEG level. Multi-operator ODU and VLAN connections will exist in optical
and packet transport networks and monitoring will be implemented using
multiple TCM/MEG levels. For Ethernet VLANs a lot of work is performed by
MEF to get this supported in the Ethernet Services layer (Ethernet VLAN
based transport service layer).

Regards,
Maarten

Regards,
     Sasha

> Subject: RE: [mpls-tp] Doesn't Occam's Razor apply to networking? 
> TandemConnections/Segments exist within SDH, ATM, OTN and Ethernet. 
> They are also defined in MPLS-TP and the identification is performed 
> via label stacking. Each of the listed technologies has its own method 
> to identify the TCM/Segment monitoring levels within the frames.
>
> There are different PW and LSP types identified in the framework 
> document and there are three layers specified in RFC5654. What I 
> request is to identify which PW/LSP belongs to which layer.
>
> relationship between PW/LSP and layer is mentioned, but this is not 
> done consistently throughout the document.
>
> identifies the transport service layer and the LSP demux label 
> identifies the transport path layer.
> On page 23 it is stated that "Service labels are typically carried 
> over an MPLS-TP LSP edge-to-edge
> It seems that an edge-to-edge LSP belongs to the transport path layer, 
> and that such edge-to-edge LSP is used when more then one service 
> exists between two PEs.
>
> Section 3.7.1 introduces Segment LSPs, but does not list to which 
> layer these belong. My understanding is that Segment LSPs will be 
> present in the trnasport service layer (to support TCM function for 
> Service LSPs and PWs), in the transport path layer (to support TCM 
> function for Edge-to-edge LSP) and section layer (to support TCM 
> function for Sections). But an understanding is an interpretation of 
> an ambiguous standard.
> My request is
> to remove this ambiguity and explictly specify in which layers segment 
> LSPs are applicable. If and when such segment LSPs are deployed is a 
> choice of the operator.
>
> Section 3.11 introduces PST LSPs, but does not list to which layer 
> these belong. My understanding is that PST LSPs will be present in the 
> transport path layer (to support group protection of transport path 
> layer transport paths (e.g. edge-to-edge LSPs). But an understanding 
> is an interpretation of an ambiguous standard. My request is to remove 
> this ambiguity and explictly specify in which layers PST LSPs are 
> applicable. If and when such PST LSPs are deployed is a choice of the 
> operator.
>
> Regards,
> Maarten
>
> My reading of this statement (FWIW) is that, from Maarten's point of 
> view MPLS-TP architecture must follow the guidelines describing the 
> data plane of SONET/SDH even if this results in introduction of 
> artificial constructs (like segment LSPs) which are nor related to the 
> MPLS reality. If not, the objectives of MPLS-TP will not be achieved.
>

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Feb 2010 17:39:37 +0200

Maarten,
I am really sorry to say that, but your description of how TCM should work in MPLS-TP does not make any sense to me.

E.g., you say that:

<quote>
        If the transport path existed prior to the activation of the additional MEG level in the transport path, it is a
        requirement that the set up of the Segment LSP does not change the path through the
        network of the original transport path. The two main things that must be done in such case are:
        1) activation and configuration of the MEP functions at the appropriate NNI or UNI-N ports
        2) change the label values identifying the transport path within the Segment LSP to the new Segment LSP label values.
<end quote>

IMHO and FWIW. this statement includes several inconsistencies.

1) AFAIK, the transport paths in MPLS-TP are LSPs (otherwise we would not be discussing them
    in the context of MPLS-TP). If an LSP does not exist, its segments do not exist either, so
    there is nothing to monitor. BTW, this is very much different from SDH

2) If you change the label values of the original LSP to something else, you create a new LSP.
    There is no linkage between the behavior of the trigeminal LSP and the behavior of the new
    one. E.g., the ILM entry in one of the nodes traversed by the segment
    you want to monitor and indexed by the incoming label of the monitored LSP in this node
    may contain erroneous information resoling in loss of connectivity for this LSP.
    When you change the labels, you start using new ILM entries which may happen to
    contain correct information, and the original problem will disappear. Of course, the
    reverse situation is also possible, i.e., the original LSP could be OK in the monitored segment,
    but once you started using new labels, you errors may occur. IMHO and FWIW, this kind of
    OAM is worse than no OAM at all.

Hopefully these notes clarify my position.

My 2c,
     Sasha

> Sent: Monday, February 01, 2010 4:55 PM
> To: Alexander Vainshtein
> Cc: [email-masked]; [email-masked]
> Subject: RE: Segment LSPs (was: [mpls-tp] Doesn't Occam's
> Razor apply to networking?)
>
> Hi Sasha,
>
> See inline...
>
> > (was:
> >         LSP, segment LSP, edge-to-edge LSP, PST LSP, etc),
> OAM and TCM
> > there is also
> point of
> specifications of