Subject: Comments on PWE3 Requirements draft

From: [email-masked]
Date: Fri, 20 Dec 2002 14:14:34 +0000

Please see below for some comments on draft-ietf-pwe3-requirements-04.txt. 
My comments are prefaced by MB>.

Best regards,

Matthew
--------------------------------------------------------------------------

4.1.3.  Support of Multiplexing and Demultiplexing

   If a service in its native form is capable of grouping multiple
   circuits into a "trunk", e.g. multiple ATM VCs in a VP or multiple
   Ethernet VLANs in a port, some mechanism SHOULD be provided so that a
   single PW can be used to connect two end-trunks.  From encapsulation
   perspective, sufficient information MUST be carried so that the
   egress of the PW can demultiplex individual circuits from the PW.

MB> This section is confusing because all layer 2 protocols are capable of 
multiplexing. There is also no definition of the term trunk; this could 
mean virtual port, or physical port, or just about any grouping of 
circuits. What I believe we are talking about here is grouping multiple 
circuits in a PW, not multiple circuits in "trunks". Can I propose that we 
replace this paragraph with:
"Sometimes it is desirable to carry multiple circuits of a native service 
on a pseudo-wire. The encapsulation should therefore carry sufficient 
information to enable these circuits to be demultiplexed from the PW."

4.2.  Frame Ordering

   When packets carrying the PW PDUs traverse a PW, they may arrive at
   the egress out of order. For some services, the frames (either
   control frames only or both control and data frames) must be
   delivered in order. For such services, some mechanism MUST be
   provided for ensuring in-order delivery. Providing a sequence number
   in the PW header for each packet is one possible approach.

MB> Sequence numbers do not enable frames to be delivered in order - need 
would need additional mechanisms which we don't, and shouldn't, define. 
They do, however, enable out of order frames to be detected. Can I 
therefreo suggest that the last sentence of section 4.2 be modified to 
read:
"Providing a sequence number in the PW header for each packet is one 
possible approach to detect out of order frames. Mechanisms for 
re-ordering frames are out of scope of PWE3."

4.4.  Segmentation and Reassembly

   It is desirable to avoid packet Segmentation and Reassembly (SAR).
   One way to do thus is to ensure that the combined size of the payload
   and its associated PWE3 and PSN headers do not exceed the PSN path
   MTU.

   If SAR cannot be completely avoided, at a PW ingress, if the length
   of a packet resulted from encapsulation exceeds the PSN path MTU, the
   PDU MAY be dropped. In this case, the management plane of the ingress
   PE MAY be notified. Alternatively, a segmentation mechanism MAY be
   defined and used. At a PW egress, if the length of a L2 frame that is
   restored from a PW PDU exceeds the MTU of destination PWES, it MUST
   be dropped. In this case, the management plane of the egress PE MAY
   be notified.

MB> What is described here is fragmentation, not segmentation and 
reassembley. Please change the terminology here. Also, fragmentation is 
not just needed when the MTU is exceeded. Some native service control 
messages, e.g. ATM OAM, may need fragmentation to support correct 
operation. 

4.5.  Handling Control Messages of the Native Services

   Some native services use control messages for maintaining the
   circuits. These control messages may be in-band, e.g. Ethernet flow
   control or ATM performance management, or out-of-band, e.g. the
   signaling VC of an ATM VP.

   It is desirable that the PEs participate as little as possible in the
   signaling and maintenance of the native services. However, it is up
   to each specific PWE3 approach to specify what the PEs MUST do in
   this regard.  For an emulated service, it is possible that some
   control messages (e.g. OAM) are processed at the PEs while others
   (e.g. keep-alive) are passed through transparently like data messages
   to the remote CE.  If control messages are passed through, it MAY be
   desirable to provide higher reliability for them. The mechanisms for
   providing the high reliability NEED NOT be defined in the PWE3 WG.

MB> Second paragraph, first sentence. We have to do signalling regardless 
in order to establish the pseudo wires. What I think we mean here is that 
the PEs do not translate signalling and maintenance messages of thew 
native service control. 

4.6.  Consideration of Per-PSN Packet Overhead

   For ATM emulation, if each packet carries one cell, the PSN tunnel
   header overhead is relatively large. In order to reduce overhead,
   multiple cells MAY be concatenated before a PSN tunnel header is
   added. Each encapsulated cell still carries its own PW header so that
   the egress of the PW knows how to process it. However, the benefit of
   concatenating multiple cells for header efficiency should be weighed
   against the resulting increase in delay, jitter and the larger
   penalty incurred by packet loss. In some cases, it may be appropriate
   to perform silence suppression or other compression.

MB> This section is ATM-specific and should be moved to the ATM services 
draft (both of the ATM cell modes support concatenation anyway).

5.  Maintenance of Emulated Services

   This section describes control plane requirements for PWE3.

5.1.  Setup and Teardown of Pseudo-Wires

   A PW must be set up before an emulated service can be established,
   and must be torn down when an emulated service is no longer needed.
   Setup and teardown of a PW can be triggered by a CLI command from the
   management plane of a PE, or by signaling (i.e. setup or teardown) of
   a PWES, e.g., an ATM SVC, or by an auto-discovery mechanism.

   Every PWE3 approach MUST define some setup mechanism for establishing
   the PWs. During the setup process, the PEs need to exchange some
   information (e.g. learn each other's capability).  The setup
   mechanism MUST enable the PEs to exchange all necessary information.
   For example, both endpoints must agree on methods for encapsulating
   PDUs and handling frame ordering. Which signaling protocol to use and
   what information to exchange are service specific. Every PWE3
   approach MUST specify them.  Manual configuration of PWs can be
   considered as a special kind of signaling and is allowed.

   Sessions in a L2TPv3 tunnel or MPLS LSPs can be used as PWs.
   Selection of a particular type of PWs is carrier-dependent and is
   outside scope of the PWE3 WG.

MB> I think the last paragraph of this section is redundant and can be 
deleted.

5.2.  Status Monitoring

   Some native services have mechanisms for status monitoring. For
   example, ATM supports OAM for this purpose.  For such services, the
   corresponding emulated services MUST specify how to perform status
   monitoring.  The mechanisms NEED NOT be defined in this WG. Some
   status monitoring mechanisms defined in other WGs, e.g. [LSPPING],
   may be leveraged.

MB> Are you saying that the native service OAM must be interworked with 
some such mechanism in the PSN, or that it is tunelled? Thsi should be 
clarified as it is very unclear in this document at which points we are 
talking about interworking native service and PW messages, and which we 
are tunelling though the PSN.

5.3.  Notification of Status Changes

5.3.1.  Up/Down Notification

   If a native service is bi-directional, the corresponding emulated
   service can only be signaled up when the associated PWs and PSN
   tunnels in both directions are functional.

MB> "signalled up" is confusing. Do you mean "established"? If not, and 
you mean signalling, then this is not necessarily true as you can 
interwork signalling in the native service with say, signalling in the 
PSN, without the corresponding PWs being "up".

   Because the two CEs of an emulated service are not adjacent, a
   failure may occur at a place such that one or both physical links
   between the CEs and PEs remain up. For example in Figure 1, if the
   physical link between CE1 and PE1 fails, the physical link between
   CE2 and PE2 will not be affected and will remain up. Unless CE2 is
   notified about the remote failure, it will continue to send traffic
   over the emulated service to CE1. Such traffic will be discarded at
   PE1.  Some native services have failure notification so that when the
   services fail, both CEs will be notified.  For such native services,
   the corresponding PWE3 service MUST provide a failure notification
   mechanism.

   Similarly, if a native service has notification mechanism so that
   when a network failure is fixed, all the affected services will
   change status from "Down" to "Up", the corresponding emulated service
   MUST provide a mechanism for doing so.

5.3.2.  Misconnection and Payload Type Mismatch

   With PWE3, misconnection and payload type mismatch can occur. A PWE3
   approach MAY define some mechanism for detecting and handling
   misconnection and payload type mismatch.

5.3.3.  Packet Loss, Corruption, and Out-of-order Delivery

   A PW can incur packet loss, corruption, and out-of-order delivery.
   This can impact the working condition of an emulated service.  For
   some payload types, packet loss, corruption, and out-of-order
   delivery can be mapped to either a bit error burst, or loss of
   carrier on the PW. If a native service has some mechanism to deal
   with bit error, the corresponding PWE3 service SHOULD provide a
   similar mechanism.

MB> It is not clear what the mapping mentioned here is. Is it an alarm? 
Also, the last sentence appears to say it is not a good idea to use MPLS 
for carrying ATM. For example, ATM provides a mechanism for detecting bit 
errors in the cell header, but MPLS provides no inherent mechanism for 
detecting bit errors. 

Section 7.2 
MB> This reads: "it is not required that an emulated service provide the 
same service quality as the native service. What quality to provide for a 
specific emulated service is a matter between a service provider (SP) and 
its customers". 

MB> Somehow this section seems to associate the level of SLA with the type 
of technology used. For example an ATM native service might have a very 
stringent SLA while the PSN PW it is riding over might have a relaxed SLA. 
I think this is not accurate. As an end customer of a native service, I 
should have some kind of SLA with my service provider. This could be very 
stringent or very loose. I do not care if my service provider carries my 
native connection over a PW inside his network, he still has to satisfy 
the contracted SLA. 
I suggest to modify this to the following: 
"If an emulated service does not provide the same quality of service as 
the native service it emulates, it is up to the service provider to 
reflect this in a new SLA with its customers." 

MB> Section 8: 
- third item should read: "to make the emulated services perfectly match 
their native services;" 

MB> Section 9: 
The first sentence does not mean anything. Indeed, the whole section seems 
confused. 
I suggest to replace the whole section with the following: 
"In order to provide the desired level of QoS to an emualted service, the 
following is needed: 
- enable the appropriate traffic management functions in the native 
service network. 
- enable the appropriate traffic management functions in the PSN network. 
- convey some native service header information in the PW header such that 
the remote PE can mark the reconstructed cells with the desired treatment 
for in the remote native service network . E.g., CLP and EFCI bits in ATM 
cell header. 
- set the PSN tunnel header with the appropriate information for the PSN 
to provide the desired treatment for the PW packets." 

----------------------------------------------
Matthew Bocci
Office of the CTO
Alcatel Broadband Networking Division
----------------------------------------------

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 20 Dec 2002 14:10:35 -0500

A few replies/questions inline.

         --Tom

>My comments are prefaced by MB>.

         We are referring to native services being emulated over a PSN.
In these cases, the edge router where imposition/disposition occurs
should be able to inject/translate errors that happen in the PSN into
native OAM for the service being emulated.   To clarify the text how about:

    Some native services posses mechanisms for status monitoring
    of the health of the service (e.g.: ATM defines special OAM cells).
    For such services, the corresponding emulated services MUST specify
    how to perform status monitoring, but NEED NOT be defined in this WG.
    For example, some service health monitoring mechanisms defined in other
    WGs such as [LSPPING], may be leveraged.  Routers performing disposition/
    imposition between the emulated service and the PSN should implement
    mechanisms that map between PSN errors and native OAM so as to
    appropriate notify the emulated service of the errors (if such a mapping
    can exist).

>PSN, without the corresponding PWs being "up".

         Signaled "up" refers to the operational status of the VC. I think
it might be better to clarify as:

    If a native service is bi-directional, the corresponding emulated
    service can only be considered operationally "up" when the
    associated PWs and PSN tunnels in both directions are fully
    functional.

>_______________________________________________
>pwe3 mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

"The difficult, we do immediately.  The impossible takes a little longer." 
-- Air Force Motto

http://www.mkp.com/books_catalog/catalog.asp?ISBN=1-55860-751-X

---

From: Sasha Vainshtein <[email-masked]>
Date: Sun, 22 Dec 2002 14:17:15 +0200

Thomas, Matthew and all,
Please see some comments inline (marked [Sasha]).
Hopefully they could be useful.
With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: Friday, December 20, 2002 9:11 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [PWE3] Comments on PWE3 Requirements draft
> 
> 
> 
> >multiplexing. 
[Sasha] Not exactly: e.g., HDLC does not support multiplexing
(unless you create FR on top of it).
> >There is also no definition of the term trunk; 
> this could
[Sasha] I would add "preferably (or possibly) by carrying the native 
demultiplexing information intact across the PSN".
... snipped ...
> >draft (both of the ATM cell modes support concatenation anyway).
[Sasha] Per-PSN packet overhead consideration is relevant for
TDM services as well (even if the current version of the
document has been carefully purged of any references to these).
Hence I suggest that the section should remain but re-worded to avoid
the impression that it is ATM-specific.
... snipped ...
>     appropriate notify the emulated service of the errors (if 
[Sasha] I believe that we have two different issues here:
1. What happens to OAM of the native service (if it exists)? E.g.,
   how does the PW ingress treat the AIS indication it detects
   in its incoming AC (applicable at least to ATM and TDM
   services)?
2. How to convert PSN errors into OAM indications of the native
service (assuming that the latter exist)? E.g., how is the
(detected) packet loss handled?

IMHO these issues should be discussed separately. The 
current text does not distinguish clearly between them.
>     associated PWs and PSN tunnels in both directions are fully
[Sasha] My understanding is that a PW is bi-directional, and, what's
more, that a single bi-directional PW emulates a single bi-directional 
service (regardless of the number of LSPs that are used for this purpose).
Hence the plural in the text suggested by Thomas seems to be misused.
... snipped ...
> >reflect this in a new SLA with its customers."
[Sasha] I do not think that we should use the term "SLA" in this
document. I seem to remember that people have agreed on the term
"SLS" (standing for the Service Level Specification) as the technical
notion instead. And I am not sure that this document can specify
the (business) behavior of a service provider (as the text suggested
by Matthew seems to do).
... snipped no the end ...

---

From: Akiva Sadovski <[email-masked]>
Date: Sun, 22 Dec 2002 17:21:40 +0200

Thomas, Matthew and all,
Some comments inline...

Best,
  Akiva

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, December 20, 2002 4:15 PM
> To: [email-masked]
> Subject: [PWE3] Comments on PWE3 Requirements draft
> 
> 
... snipped ...
> errors in the cell header, but MPLS provides no inherent 
[Akiva] IMHO the intention was to state that in case of f.ex. ATM-over-MPLS
we may "map" each MPLS packet loss to, say, AAL5 CRC Error (in case we're 
carrying AAL5) to leverage native service mechanisms dealing with such
errors.
  This approach is especially useful in the domain uncovered by these
Requirements - TDM-over-PSN for emulation of performance monitoring
parameters of "classic" 
carriers of TDM circuits (e.g., SONET/SDH) 
(draft-vainshtein-pwe3-ucesopsn-00 5.6. Performance Monitoring,
 draft-pate-pwe3-sonet-vt-00 9.4 Performance Monitoring)

---

From: [email-masked]
Date: Mon, 23 Dec 2002 03:41:53 -0000

Matthew....generally I agree with your comments.  However, I am not
impressed at all with just these extracts I see here, and I have some
serious observations on several issues.  

regards, Neil

> Sent: 20 December 2002 14:15
> To: [email-masked]
NH=> This is multiplexing *between* layer networks....which is correct/fine.

>    Ethernet VLANs in a port,
NH=> This is *not* multiplexing between layer networks.....and when people
talk of so-called 'port modes' this is an arch inappropriate concept that
should be strongly deprecated.  If one is 'emulating a port' (whatever that
actually means), the only viable context is the emulation of the physical
media signal relevant to that port.

> some mechanism SHOULD be 
> provided so that a
NH=> I am very conscious of the need to minimise the creation of new
transport entities that have to be managed....if we are not careful we will
end up creating things that actually start to look like layer networks.  If
both the client layer network and the server layer network are properly
specified, the interworking function (strictly the 'adapatation' from G.805)
between them should be minimal.  This should be the main goal in all PWE3
work IMO.
> MB> This section is confusing because all layer 2 protocols 
NH=> Not sure what you mean here...is this wrt to a different technology
higher level entity or a same technology entity? In former case - Most layer
2 protocols (or more generically the co pkt-sw mode) don't have a PID
field......there is an assumed single/invariant payload over the life of the
trail.  In latter case - ATM has 2 layer networks at VP and VC levels, and
yes VCs can be multiplexed into VPs.  FR is a single layer network
technology with no same-technology multiplexing capability.  MPLS can (in
theory) have an unbounded set of recursive (multiplexing) layer network
relationships.

> information to enable these circuits to be demultiplexed from the PW."
NH=> Whether you are conscious of this or not, this is for sure a step in
the direction of creating a new layer network entity, or proxy for such,
that will need to be managed.
> re-ordering frames are out of scope of PWE3."
NH=>SNs introduce a very real need for proper management of their behaviour.
However, in connection-oriented technologies like MPLS there should be no
out of order delivery under failure-free conditions.  If some vendors do
give misordering as a 'feature' I'd suggest they just declare this so we can
avoid buying their kit.  I think SNs should *not* be provided in the
adaptation function at all for MPLS....at a network level, they are possibly
only appropriate for a cnls forwarding mode, or more usually an application.
However, if they are to be provided then they should be fully specified. So
I'd want to see the following things considered and defined:
-	differentiating a quiescent traffic case from a failed traffic case
(does not apply to TDM 'always on' clinet case in the same way as to pkt
client case);
-	differentiating (esp wrt SN wrapping) a low traffic load with
low-loss case from a high-traffic load with high-loss case;
-	further, the (i) loss and (ii) misordering behaviour which
constitutes the failure state of each of these conditions must be defined in
terms of entry/exit criteria and consequent actions.  In terms of consequent
actions, the minimum consideration must be some form of management/alarm
indication, and a FDI (Forward Defect Indicator) must sent to the client
layers (and in the form they expect) to suppress alarms therein.

Hopefully, the above is starting to illustrate my concerns about creating
new semi-layer network entities.  In some cases (ie MPLS) this is an
architectural mistake IMO.  I am sorry if some reading this disagree with
me, but if we want to create worthwhile carrier-strength standards here that
operators will want to embrace (esp as a convergence technology in the co
pkt-sw space) then we should try and get the arch right.
> messages, e.g. ATM OAM, may need fragmentation to support correct 
NH=>I agree.  This is not a SAR function but 'fragmentation' within the peer
layer considered......these are quite different.
Note - SAR does not just apply to ATM, as other technologies can 'spread'
their client signals over the server payload area (providing they maintain
correct sequencing of such a 'spreading').  For example, SDH performs a SAR
function on every pkt it carries.  Go check how SDH carries clients if you
fail to see what I am saying here....in essence different VCs (virtual
containers) are octet interleaved over the SDH frame.  So I think this
section should be re-titled 'Fragmentation' and it's text re-worded
accordingly.
> the PEs do not translate signalling and maintenance messages of thew 
NH=> Again I agree. What we want here is an architecture that adheres to
G.805 and G.809 (co and cnls functional architecture specifications).  *If*
we are discussing the simplest client/server model (and not
protocol-conversion of the 'service I/W' case) then Matthew is absolutely
right.....the traffic of the user-plane, the control-plane and the
management-plane must be carried transparently.  That said, there must also
be correct failure handling behaviour *between* the client and server
layers.  And this is why in the case of an MPLS server layer I am so adamant
that Y.1711 must be used.....this allows proper separation of client and
server fault-handling behaviour, and so is architecturally clean and
consistent for all applications.  If you don't use Y.1711 then you will have
to provide the same functionality by some other standardised means (but
which don't exist).  Further, if Y.1711 is not used there will be an
increased temptation to try and kludge/or proxy for it in the adaptation
function.....this is not a smart move.
> draft (both of the ATM cell modes support concatenation anyway).
NH=> Agreed.  Its also mixing things up.....the reference to 'silence
suppression' for example is a voice application specific issue, not a
general client layer issue.
> are tunelling though the PSN.
NH=> Agreed.  Any half-decent layer network has fault management.  One
simply requires a simple client/server relationship where both client and
server layers are independently and properly specified in all aspects.
> PSN, without the corresponding PWs being "up".
NH=> Agreed.  A great deal of the terminology is woolly IMO.  I just wish
more people would get au fait with G.805 and G.809 that describe the
functional arch of networks as this would force some degree of rigour into
the work and help avoid kludges.

There are several issues here:
-	For a start, the user-plane traffic and the control-plane traffic
(signalling or routing) are *independent* in each of the client and the
server layer networks....and both aspects are for sure independent *between*
the 2 layers.  The degree of 'same layer' independence varies on whether the
network mode is cnls, co pkt-sw or co cct-sw.  In general the control-plane
protocols should never proxy for user-plane OAM.  Further, failure of the
control-plane (either its own disjoint data-plane, which can be true in some
modes, or the protocols therein) should not generally take down the
user-plane;
-	There is a very important performance metric called 'availability'.
In the case of bi-directional transport entities if *either* direction fails
*and* the criteria for entering the unavailable state is broached, then
*both* directions are deemed unavailable. This has important consequences
for any QoS metric processing that is in effect.  Note these points:
	* QoS processing is unidirectional and not bi-directional;
	* QoS processing is only valid whilst the trail is in the available
state, and must be suspended (at least for long-term aggregation against
metric objectives in SLAs say) when the trail becomes unavailable;
	* so if either direction fails and enters the unavailable state,
then QoS metric processing at *both* ends must be suspended.

Further, to have any chance of getting this right you must previously have
considered:
-	how to specify every defect (of the clinet or server layer as
independent layers) in terms of entry/exit criteria *and* consequent
actions....a key one of which is actually telling the affected client layers
of server layer failures, else alarms storms.  Note carefully that defect
detection/handling has to be a uni-directional behaviour. 
-	defined unavailable state entry/exit criteria and consequent actions
(eg the QoS suppression bit I noted above) and how to relay this between
either end in the case of bi-directional entities.

Now all of the above is specified comprehensively in Y.1711 for MPLS, and
its been done in such a way as to make it as simple as possible.  This
includes near-end and far-end availability processing state diagrams.  I
would suggest all those working/interested on these topic please go and read
Y.1711 (and Y.1710 which is the complimentary requirements/arch-principles
specification). 

>    CE2 and PE2 will not be affected and will remain up.
NH=> And so they should/must.....the L1 trails here come from a completely
different network space, eg SDH or something else.

>  Unless CE2 is
>    notified about the remote failure,
NH=> This is wrong.  It's not about telling 'CE2' per se, its about telling
*all* the affected clients (above) the failed trail between CE1 and PE1.
This should be done via some form of FDI from the point at which the failure
is first detected.......and this depends on which layer has failed and which
layer networks are being considered.  If its an SDH layer, this may even be
in a SDH node that lies somewhere between CE1 and PE1.  If its the L1 trail
into PE1 directly, then its the responsibility of PE1

> carrired on the failed it will continue to send traffic
>    over the emulated service to CE1.
NH=> So?  In fact it should in the case of a unidirectional failure in
direction CE1->PE1.

> Such traffic will be discarded at
>    services fail,
NH=> What does 'when the *services* fail' mean here?

 both CEs will be notified.  For such native 
> services,
NH=> Absolutely wrong.  If there is a failure between CE1 and PE1 this has
to be handled by the OAM of *all* the layers afffected (ie at and above the
level of the failure), and this includes the client layer network of this
case.  If the clinet layer has properly specified OAM then it can look after
itself here....and since this is the situation stated above, then what is
said is not even right/applicable in this case.  If the client can't look
after itself because it was poorly specified then that's tough....the client
needs fixing here.....so don't go kludging the PSN to provide it....or any
other layer networks.  In fact, a failure here has nothing to do with the
PSN and the PSN must not indicate any failures.....nor must the lower layer
(L1) networks in the direction PE2->CE2.  Nor has it strictly anything to do
with this 'new' layer network entity (the 'PW') that is being created, but
is not well defined.  Keep things nice and simple as client/server and make
sure each layer network is independently and properly specified in the first
place (and don't compound the errors of history by compromising that
here)....that should be the key goal IMO. 
>    MUST provide a mechanism for doing so.
NH=> Wrong.  If the client is properly specified, as seems to be the case
being referred to, it will tell itself when things come back up.  All the
server has to do is transport the client transparently. Please keep layer
networks independent.
>    With PWE3, misconnection and payload type mismatch can 
> occur.
NH=> With PWE3???  I think this should be a technology specific issue.  IP
pkts are cnls, and so contain absolute source/sink network
addresses......they can't get 'misconnected'.  MPLS is a co pkt-sw
technology.  A hallmark of any co pkt-sw technology is the use of
link-identifiers that are not globally unique, but only link unique.  In
MPLS these are called 'labels' (in ATM its a VPI/VCI and FR its a DLCI).
Link-identifiers only have currency when they are allocated (via
provisioning or signalling) to a parent trail.  Since link-identifiers are
only link (or in some cases of MPLS node) unique, then the same
link-identifier can occur on many different links associated with the same
or different trail. This means one can get swapped traffic, or unintended
replication of traffic between trails (ie traffic leaking from one LSP into
another LSP) which would be undetectable.  These failure modes only apply to
co pkt-sw networks and not cnls networks.  To detect such failures it is
important that the trail sink periodically checks that it is connected to
the correct source.  All these defects (and more) are specified in Y.1711
and the CV pkt is designed to detect them by carrying a source unique
address, known as the TTSI (trail termination source identifer),
periodically to the sink, eg by the loss of expected CV_TTSI arrivals or the
observation of unexpected CV_TTSI arrivals for a specified time.

>    A PWE3
NH=> Why only 'may'?  In fact this has nothing to do with PWE in the case of
MPLS, as the above is an inherent functional property required of MPLS
itself.  And this is what I was trying to point out earlier....if you get
the basic specification of a layer network right, then you don't have to go
creating new layer network proxies (that then need to be managed) in some
interworking function between them when operating in a simple client/server
mode.
>    A PW can incur packet loss, corruption, and out-of-order delivery.
NH=>  Why should one get misordered delivery in an MPLS co pkt-sw network?
If you do then the technology needs fixing by the vendor.  Further, the QoS
metrics of loss/errors/etc are relevant to the layer network in
question.....*not* the interworking adaptation bit.  If these metrics are
properly specified/measured in both the client and server layer networks
then what is the problem to be fixed here?

>    with bit error, the corresponding PWE3 service SHOULD provide a
NH=> I fundamentally disagree.  Each layer network should be specified
independently...and if it is then what has PWE3 got to do with this?
> MB> It is not clear what the mapping mentioned here is. Is it 
NH=> Matthew I agree.....and as you will have noted from my prior remarks,
if you start creating these semi-layer network proxies then yes, you will
have to make sure you fully specify their defect handling behaviour.  But if
you do the right thing and get each layer network prioperly specified in the
first place, most of these kludges aren't needed.

> MB> Also, the last sentence appears to say it is not a good idea 
> to use MPLS 
NH=> However, that's something for MPLS to address, not some 'PW' IWF.  But
let's get the basic defect handling stuff right first in MPLS....because if
this is not right then you can forget anything else.
Note - We have a 'P' flow in the living-list of Y.1711 (for ages now) just
for such metrics.  But this is a 2nd/3rd order thing to worry about after
the basic fault-handling *and* availability metric is sorted.  We can now
turn attention to that if we want to.
> specific emulated service is a matter between a service 
NH=> True for the *objectives* but not for the *metrics*....these have to be
standardised.  Further, if the basic technology behaviour is not correctly
specified you have a major problem.....garbage-in, garbage-out (for the
NMS/OSS).
> reflect this in a new SLA with its customers."
NH=> Agreed, but speaking as an operator I don't want to see all this stuff
kludged and technologies compomised due to poor expedient design.  MPLS
offers a major opportunity for co pkt-sw functional convergence for
operators....and this impacts capex/opex costs.  So for those who are happy
with lower-grade solutions then that's fine, but that is not true for all.
If this stuff can't be specified for certain technologies in this forum to
what I believe is the right level to provide carrier-strength solutions,
then maybe a different level of specification  should be done elsewhere.
> to provide the desired treatment for the PW packets." 
NH=> And please add Y.1711 for MPLS....because if you cannot even correctly
fault-manage this stuff for us, then don't bother tinkering at the
QoS/traffic level.

---

From: [email-masked]
Date: Mon, 23 Dec 2002 06:12:35 -0000

Akiva...please see below...regards, Neil
<snipped>
> carrying AAL5) to leverage native service mechanisms dealing with such
NH=> Please don't do things like this.....try and keep the layer networks
independent.  Failures/QoS hits in the MPLS network are relevant to the MPLS
network only.  If the client sees a problem let it detect/handle it using
its own methods.

>  draft-pate-pwe3-sonet-vt-00 9.4 Performance Monitoring)
NH=> This sentence mentions TDM but the previous one mentions ATM AAL5....I
don't see the conection.

---

From: [email-masked]
Date: Mon, 23 Dec 2002 06:12:34 -0000

Sasha...please see below.  regards, Neil
<snipped>
(wrt section 5.2) 
>    in its incoming AC (applicable at least to ATM and TDM
NH=> It should pass all client layer traffic transparently, including FDI
(AIS).

> (detected) packet loss handled?
NH=> By making sure that each/every layer network has independent
fault-handling so that arbitrary client/server relationships can be used as
needed.  Specifically however, failures detected at a given server trail
termination point should result in an appropriate FDI sent to the client
layer.  This is why its crucial for fault management to be uni-directional
and driven from the sink point of the failed server layer.  For MPLS please
see Y.1711....it's all done in there for you to use.
> current text does not distinguish clearly between them.
NH=> I agree.

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Dec 2002 10:00:28 +0200

Neil,
Thank you for the comments.
Please see a brief clarification/question inline.

With best regards,
                                   Sasha Vainshtein

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, December 23, 2002 8:13 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: [PWE3] Comments on PWE3 Requirements draft
> 
> 
[Sasha] I have been thinking about the so-called "structured TDM/SONET"
emulation". I think that,  from the client trail/server trail model
point of view, it means that a single client trail crosses multiple 
server trails - each with its own adaptation technique. 
In addition, there is at least one valid use case (n*DS0) where 
the native client trail does not have any OAM of its own. The idea was to 
carry some "server signal failure" (SSF) indication from the PW ingress to
egress in addition to the client layer traffic and, in some cases, 
translate it at egress in the appropriate SSF. Do you see any 
(architectural or other) problem with this?
... snipped to the end ...

---

From: [email-masked]
Date: Mon, 23 Dec 2002 12:30:16 -0000

Hi Sasha,  please see below...I think we can sort this.  Regards and seasons
greetings, Neil

> server trails - each with its own adaptation technique.
NH=> Absolutely correct.  However, as far as the client layer trail is
concerned it has no visability of the construction of each of the server
layer trails that form it's (client) link connections.....and in turn, the
link connections of the immediately below server layer trails are supported
by even lower layer trails, and so on until we hit the duct network.  It is
vital that we all understand/respect this arch model since it reflects the
real operating/commercial world.  And there are major consequences of
this.....like the need to make sure of independent layer (and plane) fault
management in a uni-directional sense at trail terminations points.  If you
adhere to good func arch concepts you will not go far wrong.
Note - Besides the classic co pkt/cct-sw G.805 functional model (which has
been around for about 14 years now) a new model that formalises the
description of cnls networks has just been completed in G.809, largely
written by a colleague of mine.  This is already being used in real
applications, eg to model an ethernet client over GFP/SDH.

> the native client trail does not have any OAM of its own.
NH=> I agree.

> The 
> idea was to 
NH=> Here is my advice:

-	The fact that the client layer signal has no OAM is (i) historic and
(ii) relates to its orginal application within either (a) the 64kbit/s
PSTN/ISDN co cct-sw world or (b) the managed-BW mux world, where a server
layer E1 or T1 frame was usually assumed.  I had a large hand in the E1
frame design way back and used to strongly encourage enterprise managed-BW
mux vendors of the day to adopt G.704/706 in order to avoid things like
false framing (via CRC4) or inconsistent framing (ie by use of proprietary
framing). Most of them listened, and now its rare to find much proprietary
framing.  Now the fact nx64k has no OAM should just be accepted as that.  If
you want to wrap some other frame round that then so be it.....but you are
now creating the beginnings of a new layer network.  Now how far you want to
go in defining all the functional components of a new layer network is
something you need to think very carefully about (in essence these are
addressing, signalling, routing, OAM, traffic descriptors and perf
metrics/objectives).  This is possible, but there is price....and as a
minimum this will be fault-management of any such *integrity checking*
functionality that is provided.

-	Whatever is done wrt to adjunct-layer framing of the client layer as
noted above, it *must not* have any impact on any other layer networks.  If
the server layer network is MPLS then that should be managed in its own
right.  This is blindingly obvious IMO since one wants the *same* consistent
management of MPLS irrepective of the client supported (or indeed of how the
LSP are instantiated....but that is another issue related to cases where a
control-plane incorrectly proxies for a bad/poor user-plane specification).
So, I strongly advise to make sure MPLS is properly specified by using
Y.1711 for fault-management and if you do so you will automatically:
	* minimise the additional work needed at the (per) client layer;
	* you will get proper defect indications from below, ie FDI, which
is essential to stop you raising alarms above MPLS.

If you agree with me on this and work towards towards such a solution then
you'll have my (and many others in operators) support.  We must try and keep
the arch clean and logical.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 23 Dec 2002 09:35:32 -0500

>is essential to stop you raising alarms above MPLS.

         I disagree unless you are referring to Y.1711fr.  Y.1711 is flawed
and should not be used for anything at this point.

>the arch clean and logical.

         I think that operators have spoken already on the topic of Y.1711,
which is why we are all working on alternative solutions.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 23 Dec 2002 09:47:37 -0500

Comments marked [TDN] below.

>current text does not distinguish clearly between them.

[TDN]   Yes. There also needs to be a provision for passing
                 native OAM through the PSN (if it exists) unaltered.

>Hence the plural in the text suggested by Thomas seems to be misused.

[TDN]   I think you need to specify this. For example, what if the underlying
                 PSN is MPLS?  In that   case, the LSPs are uni-directional 
and both must
                 be set up before the PW can be operational.

>the (business) behavior of a service provider (as the text suggested

[TDN]   Didn't catch that agreement, but the term SLS is fine.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 23 Dec 2002 10:48:39 -0500

At 05:29 PM 12/23/2002 +0200, Sasha Vainshtein wrote:
>Thomas and all,
>Please see a short comment inline.
>
>With best regards,
>                                    Sasha Vainshtein
> > Sent: Monday, December 23, 2002 4:48 PM
> > To: Sasha Vainshtein
> > Cc: [email-masked]; [email-masked]
> > [TDN]   I think you need to specify this. For example, what
> > if the underlying PSN is MPLS?  In that   case, the LSPs are
> > uni-directional and both must be set up before the PW can be operational.
> >
>[Sasha] Actually I referred to plural in case of PWs and not PSN tunnels -
>because I believe that "1 emulated service <--> 1 PW" regardless of the PSN
>and/or demultiplexing type, signaling methods used for setup/teardown etc.

         Oh, no problem, my mistake. Yes, "PWs" in the statement above
should be "PW".

         Cheers,

         --Tom

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 23 Dec 2002 17:29:33 +0200

Thomas and all,

With best regards,
                                   Sasha Vainshtein

... snipped ...

---

From: [email-masked]
Date: Mon, 23 Dec 2002 17:42:25 -0000

Hi Tom...I think you need to explain and justify some of your
comments....please see below.  regards, Neil
<snipped>
> and should not be used for anything at this point.
NH=> Please explain precisely what is technically flawed in Y.1711?  Enough
engineers who I have loads of respect for have crawled all over Y.1711 now
for a couple of years now and found nothing technically wrong with
it....seems some just don't like it for their own reasons. 
>          I think that operators have spoken already on the 
NH=> Have they?  Where is that then?

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 23 Dec 2002 15:31:55 -0500

>it....seems some just don't like it for their own reasons.

         Need I point out (again) that Y.1711 doesn't work for ldp-signaled
networks?

         --Tom

---

From: [email-masked]
Date: Tue, 24 Dec 2002 03:52:53 -0000

> > >          I disagree unless you are referring to Y.1711fr.
> > > Y.1711 is **flawed**
> > > and should **not be used for anything at this point**.
NH=> No of course not Tom....we all know that (I hope). The only reason I
bothered to respond here was because of the misinformation denoted by **
above.  The simple fact of the matter is Y.1711 is not flawed at all for the
purpose it was designed for, ie p2p (or p2mp) LSPs.  And anyone who is
tracking the MPLS WG discussion on LSP Ping will realise just how difficult
it is to fault-manage mp2p constructs.  So perhaps the problems/flaws lie
elsewhere?  Further, we have just completed some testing of one
manufacturer's products in the labs here, and Y.1711 works exactly as
intended (but a bunch of LSRs in the middle from another vendor detected no
problems).  

regards, Neil

---

From: Shahram Davari <[email-masked]>
Date: Wed, 25 Dec 2002 08:37:30 -0800

> Sent: Monday, December 23, 2002 3:32 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> > > Y.1711 is flawed

being out of scope is not a flaw. May I remind you too that based on recent debates in MPLS WG it seems that MPLS-ping has more flaws and holes than a Swiss cheese.

-Shahram