Subject: Re: [mpls-tp] Fw: I-D Action:draft-sprecher-mpls-tp-survive-fwk-01.txt

From: <[email-masked]>
Date: Mon, 2 Mar 2009 14:02:15 -0000

Thanks Adrian,

Looks like a useful document.  A few observations for consideration:

1	Transport networks are intended to provide a transparent
transport service to their clients.  So we all should be clear on what
this means:
-	the DP/CP/MP protocol instances of the client are functionally
disjoint from the DP/CP/MP protocol instances of the server.  In
particular the DP/CP/MP of the client are carried transparently over the
DP of the server.
-	all symbols of the client are treated equally (see Note)
-	client symbol ordering is preserved
-	no attempt is made to infer meaning of client symbols and they
are never changed
-	(and from performance inheritance considerations, transparency
also means that) the traffic behaviour of client X cannot impact the
performance experienced by client Y

Note - The reason transparency is very important for MPLS-TP is because
a transport network is not a top-of-stack network but is primarily used
to create the topology of higher layer networks where, ultimately, there
is always a client layer network that is top-of-stack (where
top-of-stack implies a network with no higher layer client networks and
that directly interfaces with external message/file/stream applications,
eg IP/Internet).  Transport networks have to carry a large aggregate mix
of message/file/stream applications, and whose mix composition can vary
epoch by epoch.  Now whilst the QoS (=> delay metrics) of an application
type may be fixed its survivability importance can take on any value, eg
any type of voice has essentially the same QoS requirements, but calls
to the emergency services, business calls and residential calls can have
different survivability importance's when there is a resource shortfall.
It is therefore not possible to infer an application's survivability
importance from either its type (ie message/file/stream) or its up-state
QoS requirements.  This is not simply a technical issue but it has
important operational and commercial implications.  Commercially most
clients would not want a server layer network (especially when owned by
a different party) snooping/modifying their traffic.  And operationally
it would be far too onerous/complex anyway for a transport network to
have to worry about what each individual application's QoS/survivability
requirements were within a large time-varying aggregate of applications.
And this is why transparency is important for transport networks.  We
all probably take it for granted that this is what we get from today's
PDH, SDH and OTN networks....because transparency is a forced behaviour
in the co-cs mode.  However, when we are designing a co-ps mode
transport network, like MPLS-TP, we have to consciously make sure we
design-in transparency.  And we should also note that:
-	the survivability semantic is a function of the (parent)
connection object and not the individual (child) traffic units that the
connection carries.
-	transparency implies that a connection has a single source and
that it has only a single 'QoS class'

Aside=> When reading through the document it becomes quite clear that
whoever wrote most of it has a very good understanding of the
protection/restoration subject matter and has implicitly assumed that
the above mentioned transparency requirements are indeed
respected....but nowhere are they formally stated.  IMO it would be
beneficial if these were formally recorded somewhere like in Ben's
requirements document.

2	The document mentions PWs as well as LSPs in the context of
protection/restoration in several places.  I suspect the document is
assuming that PWs can be connections (ie a MS-PW networked entity) just
like LSPs.  If this is the case then it is wrong.  MPLS-TP is supposed
to be a transport network and it has no need to create MS-PWs, and
indeed it must not spawn an unnecessary PW layer network above it.
Moreover, in order to create MPLS-TP we must remove certain
features/behaviours found in MPLS as-is, and in doing so we remove the
conditions that created the need for PWs in the first place.  So this
document should only talk about MPLS-TP LSPs and not PWs.

3	Section 4.1.3 talks about OAM messages used to detect DP defects
and correctly notes that these apply to the MPLS-TP DP.  It is therefore
important for protection/restoration actions that MPLS-TP OAM packets
look like normal MPLS-TP DP traffic packets.  This is not currently the
case.  It is assumed in draft-ietf-mpls-tp-gach-gal that OAM packets
reside under the GAL. This means OAM packets will not have the same
header as normal traffic packets.  Moreover, the GAL is primarily
required for a logical OOB (wrt DP) CP/MP channel and it is therefore
not sensible to have DP OAM packets carried in such a channel.  Since
this document is dependent on getting the DP OAM messages right, then
this needs fixing in both draft-ietf-mpls-tp-gach-gal and
draft-bryant-pwe3-packet-pw-00.txt...because the latter is trying to
define the DP encapsulation structure for MPLS-TP and the OAM indicate
flag must be included here.

4	Section 4.4.3 talks about Bypass Tunnels and says this:

"When there is a failure condition in the network segment, one or more
of the protected LSPs are switched over at the ingress point of the
network segment and transmitted over the bypass tunnel. The natural way
to realize this is using label stacking. Label mapping may be an option
as well."

Label stacking as used in MPLS implies sublayering....so this implies *a
same layer network* partial connection protection/restoration scheme.
I'm a little bit uneasy about these constructs and my gut feeling is to
prefer protection done cleanly on an end-end basis....be this the
end-end trail in this layer network, or the end-end trail in a lower
layer network (which clearly only operates over a single link connection
in the client layer network).  Here we also have unambiguous end-end OAM
flows for defect detection, and we either (i) don't bother the client
layer network at all for single link restoration in the server layer or
(ii) if restoring in the client we clear the connection to its end
points so we don't have resource problems in trying to keep the
restoration localised to near the point of failure. 

I'm not saying 'don't do partial connection protection', I'm just saying
I'm not so sure of its real benefits in all scenarios.

5	Need for a dedicated protection switching co-ordination
protocol.

This is mentioned in section 4.5.1.  I am not sure we need a dedicated
protection switching co-ordination protocol in all bidirectional cases.
If we have CV and BDI OAM functions in the DP then for some simple forms
of protection switching we ought to be able to use these, eg
-	failure of both directions means CV loss seen at both ends....so
both ends can protection switch.
-	failure detected by loss of CV in the A->Z direction at the Z
end will generate a BDI to signal this failure in the Z->A direction and
so both ends know they have to protection switch.

6	p2mp connections.

Towards the end of section 4.5.1 the document says this:

"In a 1:1 P2MP protection scheme, the source/root LSR needs to identify
the existence of a fault condition on any of the branches of the
network.  This requires the sink/leaf LSRs to notify the source/root LSR
of any fault condition. This required also a return path from the
sinks/leaves to the source/root LSR."

I think Y.1731 piggybacks the BDI indication in a CV OAM message (going
in the other direction).  But this is clearly not a good idea for p2mp
connections because (unlike p2p connections) they are not symmetric.  So
we will need to ensure that the MPLS-TP CV messages used on p2mp
connections (in direction root->leaf) don't use a piggybacked BDI
function.

Also a typo in above:  Last sentence 'required also' change to
'requires'.

7	Section 4.5.2 has a typo:

"Several Service Providers have expresses a high level of interest in
operating MPLS-TP in ring topologies and require a high level of
survivability function in these topologies."

Change 'expresses' to 'expressed'.  I'd also delete last part of
sentence that starts '...and require a high....topologies'.

8	Ibid typo:

"[MPLS-TP-REQ] introduces a list of requirements on ring protection that
cover the recovery mechanisms need to protect traffic in a single ring
and traffic that traverses more than one ring."

Change 'need' to 'needed'.

9	Ibid typo:

"As described in section 4.2 above, the recovery element may constitute
a spam, a tandem connection (i.e. either an LSP segment or a PW
segment), an end-to-end LSP, or an end-to-end PW."

Change 'spam' to 'span'.  Also see earlier remark on PWs.

10	Section 5.51 has a typo:

"However, it does provide mechanisms to detect control plane faults and
these can be can be used to deduce data plane faults where it is known
that the control and data planes are fate sharing. "

 Extra 'can be' needs deleting.

11	Might also be worth adding something to section 5.5.1 along the
lines of 'Failure of components of the CP should not take down existing
MPLS-TP DP connections'.

regards, Neil 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: 25 February 2009 14:43
> To: [email-masked]
> Subject: [mpls-tp] Fw: I-D 
> Action:draft-sprecher-mpls-tp-survive-fwk-01.txt
> 
> Hi,
> 
> Here is a new revision of this MPLS-TP draft.
> 
> We would welcome comments and suggestions for text (just hunt 
> for "TBD").
> 
> Thanks,
> Adrian and Nurit
> 
> ----- Original Message ----- 
> From: <[email-masked]>
> To: <[email-masked]>
> Sent: Wednesday, February 25, 2009 2:30 PM
> Subject: I-D Action:draft-sprecher-mpls-tp-survive-fwk-01.txt
> 
> 
> >A New Internet-Draft is available from the on-line Internet-Drafts 
> >directories.
> >
> > Title           : Multiprotocol Label Switching Transport Profile 
> > Survivability Framework
> > Author(s)       : N. Sprecher, et al.
> > Filename        : draft-sprecher-mpls-tp-survive-fwk-01.txt
> > Pages           : 34
> > Date            : 2009-02-25
> >
> > Network survivability is the network's ability to restore traffic
> > following failure or attack; it plays a critical factor in the
> > delivery of reliable services in transport networks. Guaranteed
> > services in the form of Service Level Agreements (SLAs) require a
> > resilient network that detects facility or node failures very
> > rapidly, and immediately starts to restore network operations in
> > accordance with the terms of the SLA.
> >
> > The Transport Profile of Multiprotocol Label Switching 
> (MPLS-TP) is a
> > packet transport technology that combines the packet experience of
> > MPLS with the operational experience of transport networks like
> > SONET/SDH. It provides survivability mechanisms such as protection
> > and restoration, with similar function levels to those found in
> > established transport networks such as in SONET/SDH 
> networks. Some of
> > the MPLS-TP survivability mechanisms are data plane-driven and are
> > based on MPLS-TP OAM fault management functions which are used to
> > trigger protection switching in the absence of a control 
> plane. Other
> > survivability mechanisms utilize the MPLS-TP control plane.
> >
> > This document provides a framework for MPLS-TP survivability.
> >
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-sprecher-mpls-tp-sur
> vive-fwk-01.txt
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>