Subject: Comments on draft-ietf-pwe3-requirements-03.txt

From: Eric Rosen <[email-masked]>
Date: Thu, 03 Oct 2002 10:14:25 -0400

Here are my "last call" comments, on the lines beginning with ****.

Section 3.3.1

   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 similar mechanism for doing so.

**** Delete "similar" in the last sentence above. 

Section 3.4

   If a native service has keep-alive mechanism, the corresponding
   emulated service MUST define a similar mechanism for keep-alive.

**** Delete "similar".  

**** At the service interface, one  may require that the mechanism appear to
**** the  CE to  be  exactly the  same,  but certainly  the actual  internal
**** (PE-PE) mechanisms need not be at all similar. 

4.6.  Pseudo-Wire Traceroute

   It can be desirable to know the exact path of a PW, especially for
   troubleshooting purpose. A PW emulation service MUST support PW
   traceroute.

**** The  problem with  this is  that no  definition has  been given  of "PW
**** traceroute".  Perhaps you  should just say "there MUST  be some way for
**** an operator to find out the exact path of a PW" at some particular time. 

5.1.  Characteristics of an Emulated Service

   Functionally, two CEs that are connected by an emulated service
   SHOULD appear connected by a native service, although service quality
   of the emulated service may be different from that of a native one.
   Specifically, the following requirements MUST be met:

   1) It MUST be possible to define type (e.g. Ethernet, which is
      inherited from the native service), speed (e.g. 100Mbps), and MTU
      size for an emulated service, if it is possible to do so for a
      native service.

**** Well,  even  in  ethernet there  is  no  law  against mixing  100  mbps
**** equipment and 10 mbps equipment.  All that's really well-defined is the
**** speed at  the access  interface.  So I'm  really not sure  I understand
**** what you mean here. 

   2) The two endpoints of emulated service #1 and the two endpoints of
      emulated service #2 may be connected to the same PE at each end,
      respectively. As a result, the PWs of these two emulated services
      may share the same physical paths between the two PEs.  But from
      the CEs' perspective, each emulated service MUST appear as
      unshared, that is, a CE MUST NOT be aware of existence of other
      CEs or other emulated services.

**** I do not understand this paragraph at all. 

   4) If a routing protocol (e.g. IGP) adjacency can be established over
      a native service, it MUST be possible to be established over an
      emulated service as well. Spanning Tree Protocol (STP) is not
      considered as a routing protocol and requirements on support/non-
      support of STP is outside scope of this document.

**** I don't follow  the remarks on STP.  Surely it needs  to be possible to
**** set up an STP adjacency over an ethernet PW! 

   5) The TTL fields of the PW PDUs, if exist, MUST not be changed
      inside an emulated service.

**** Either leave  this out, or  else list every  field of the PW  PDU which
**** must not be changed. 

5.2.  Service Quality of Emulated Services

   It is RECOMMENDED but not REQUIRED that an emulated service provide
   as high service quality as the native service.  However, the PWE3 WG
   only defines mechanisms for providing PW emulation, not the services
   themselves. What quality to provide for a specific emulated service
   is a matter between a service provider (SP) and its customers, and is
   outside scope of the PWE3 WG. In fact, different SPs can use the same
   PWE3 approach with different QoS mechanisms to provide the same
   emulated service with different service quality.

**** Delete the words "RECOMMENDED but" in the above paragraph.

Section 6 Scalability

**** I can't really understand the stuff on path-oriented PWs and tunnels. 

Section 7.1 RFC 2914 Conformance

**** I  am afraid  that this  section  is not  very useful  as it  currently
**** exists.   I would  either leave  it out  altogether or  else  expand it
**** greatly.  I don't think we can accept the document with this section as
**** is, because we certainly cannot state that there is any WG consensus on
**** what the  congestion control requirements are, and  on whether RFC 2914
**** (which is not a standard) is a proper statement of them.

10.  Inter-domain Pseudo-Wires

   The PWE3 WG will determine the requirements for having a PW pass
   across an administrative boundary.  An edge could be a native hand-
   off or hand-off to a further PW.  The working group may analyze
   requirements for both security and performance for the inter-
   administration technology. This topic is for further study.

**** I don't understand this.  If the  PW goes through a tunnel that crosses
**** admin  boundaries,  then  the  PW  will pass  across  admin  boundaries
**** transparently. What are you really trying to say? 

11.3.   Security Considerations for Use of Non-path-oriented PWs

   If Non-path-oriented PWs are used, some security mechanism MUST be
   provided to ensure that packets received at an egress PE are indeed
   sent from the corresponding ingress PE.

**** I don't  think that integrity is a  requirement, but if it  is, I don't
**** see why the issue of  path-oriented vs. non-path-oriented PWs is of any
**** relevance.

---

From: "David Allan" <[email-masked]>
Date: Thu, 3 Oct 2002 10:41:06 -0400

Tom:

<snipped>

> 
> >The p2p case of LSPs is trivally solved with Y.1711...
> 
>          Only if you are referring to the IP-based 
> contributions to y.1711,
> which is in essence LSP Ping.  As you know, the original part of that
> specification will not work for  LSP-signaled LSPs in any 
> networks I know
> of.

Neils comment on Y.1711 CV was correct and had nothing to do with LDP (which
is what I presume you meant) except perhaps when P2P labels are handed out
between PEs using extended discovery. And to avoid confusing the issue,
LSP-PING is an input to Y.17fw, which is a SG13 work in progress that is a
follow on effort from Y.1711. 

Dave

---

From: Danny McPherson <[email-masked]>
Date: Thu, 03 Oct 2002 09:20:44 -0600

> Danny, Xipeng, Stewart, Max  and all,
> At the Yokohama WG session, Danny has suggested a merge between
> the common requirements document and a dedicated requirements
> document for emulation of TDM services (draft-riegel).
> It looks now that this idea has been dropped. Is it correct?

Yes.  The current thinking is that the TDM requirements
should reside in a stand-alone document.  Does anyone have
problems with this?

> In addition, please see some comments inline.
> Hopefully they will be useful.
> BTW, some of these comments deal with what looks to me as
> improper extension to L1 (TDM) circuits of terms and notions 
> associated with L2 (frame-oriented) ones. 

Thanks, we'll review these...

-danny

---

From: Peter Willis <[email-masked]>
Date: Thu, 03 Oct 2002 16:53:43 +0100

> **** an operator to find out the exact path of a PW" at some particular time.

Eric's suggested wording is better. Perhaps we could clarify "exact path"? 
Does this mean the path of the data as contrasted with the path the control 
plane "thinks" the data is taking? In any case it would be good to know both 
the path of the data and the path the control plane "thinks" the data is 
taking. So perhaps a better wording is

"there MUST be a mechanism for an operator to find out the actual path of the
 packets carrying the PW and the path of the PW as determined by the control 
plane"

Peter Willis.

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 03 Oct 2002 17:04:08 +0100

> should reside in a stand-alone document.  Does anyone have

I think that would be a good idea, although I am not sure that
TDM is the right genereic term.

If we go that way, then a statement to that effect needs
to be included in the requirements draft, and the requirements
draft probably needs a change in title to reflect its scope, ie
something like "base-requirements" or "packet and cell requirements"

Then we need to go through the "base-requiements" document and
remove all references to TDM.

Stewart

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 03 Oct 2002 12:02:40 -0400

At 07:13 AM 10/3/2002 -0700, Shahram Davari wrote:

> >          --Tom
>What do you mean LSP-signaled LSPs?

         Typo: LDP-signaled.

         --Tom

------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 03 Oct 2002 12:12:42 -0400

At 10:41 AM 10/3/2002 -0400, David Allan wrote:

>Neils comment on Y.1711 CV was correct and had nothing to do with LDP 
>(which is what I presume you meant) except perhaps when P2P labels are 
>handed out between PEs using extended discovery. And to avoid confusing 
>the issue, LSP-PING is an input to Y.17fw, which is a SG13 work in 
>progress that is a follow on effort from Y.1711.

         The p2p case is not trivial if you use y.1711 to do CV on the
underlying LDP-signaled LSP.  LSP ping is the right mechanism
to use (which is described in the new input to y.17fw as well as in the
MPLS I-D).  But we digress from the original point, which was to
adjust the language in the requirement document.

         --Tom

---

From: [email-masked]
Date: Thu, 3 Oct 2002 09:56:55 -0700

For my clarification, does it mean that we will have requirements documents for each service separately? 
- TDM services
- Ethernet private line services

Vinay

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Thursday, October 03, 2002 8:21 AM
To: pwe3
Subject: Re: [PWE3] comments on draft-ietf-pwe3-requirements-03.txt 

-danny

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

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 3 Oct 2002 19:18:47 +0200

Danny and all,
Please see inline.

With best regards,
                                   Sasha Vainshtein
email:     [email-masked] <mailto:[email-masked]> 
tel:       +972-3-7659993 (office)
           +972-8-9254948 (res.)
           +972-58-674833 (cell.)

> Sent: Thursday, October 03, 2002 5:21 PM
> To: pwe3
The only problem I see is misuse of L2 terms and notions
when it comes to L1 circuits emulation in the requirements 
document. IMHO some clean-up is required, but, of course,
it can be done on a stand-alone basis as well.

---

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 3 Oct 2002 18:01:14 +0200

> From: Stewart Bryant [mailto:[email-masked]]
> Sent: Wednesday, October 02, 2002 9:25 PM
> To: pwe3
> Subject: [PWE3] comments on draft-ietf-pwe3-requirements-03.txt
> 
> 
> Some comments on <draft-ietf-pwe3-requirements-03.txt>
> 
> Stewart
> 
> <snip>
> 
> 1.1.  Reference Model of PWE3
> 
>     A pseudo-wire (PW) is a connection between two provider edge (PE)
>     devices which connects two pseudo-wire end-services (PWESs) of the
>     same type. A PWES is either:
>       - an Ethernet link or a VLAN link between two ports, or
>       - an ATM VC or VP, or
>       - a Frame Relay VC, or
>       - a TDM circuit, or
>       - an MPLS LSP
> 
> SB> Why not raw HDLC frames?
> SB> Do you mean TDM or something more generic? How does SONET fit in
> SB> to this taxonomy?]
>
[Sasha] The WG charter says "TDM (e.g., DS1, DS3, SONET)".  De-facto
[Sasha] most people tend to include E1 and E3 under the TDM umbrella
[Sasha] as well. To me this answers the 2nd question posted by Stewart.
[Sasha] Maybe the document should mention the dichotomy between structured
[Sasha] and unstructured TDM.
[Sasha] As for "something more generic", I would like to see at least a
couple
[Sasha] of real-life examples first. (Of course, it does not mean that we
[Sasha] should not try to deal generically with common properties of 
[Sasha] known structured and unstructured TDM services).
>
> 
>     between a customer edge (CE) device and a PE (See Figure 
> 1).  During
>     the setup of a PW, the two PEs will be configured or will
>     automatically exchange information about the service to 
> be emulated
>     so that later they know how to process packets coming 
> from the other
>     end. After the PW is set up, layer-2 (e.g. Ethernet, ATM, 
> Frame Relay
>     and MPLS) or layer-1 (e.g. SONET/SDH) PDUs from a PWES are
>     encapsulated at the PW ingress. The encapsulated PDUs are 
> then sent
>     over the PW to the egress, where L2 or L1 headers are 
> re-constructed
> 
> SB> headers may be reconstructed if necessary - they might after all
> SB> have been sent intact
>
[Sasha] I reserve some doubts regarding the terms "L1 header"
and "L1 PDU".
The least I can say is that these terms do not appear often 
in the TDM circuits' specifications. E.g. G.707 (the ITU-T 
document defining SDH) uses the term "header" only when 
discussing mapping of ATM cells into the SDH payload, 
and, in this case, it refers to ATM cell headers.
On the other hand, I do not have any bright ideas regarding
more appropriate names.
>
>     and the resulted frames are forwarded in their native 
> format to the
>     other CE.
>
[Sasha] The term "frame" has different meaning in case of L2 and L1
[Sasha] circuits, too. 
> <snip>
snip
> 
>     Path-oriented PW   A Path-oriented PW is a PW for which 
> the network
>                        devices of the underlying PSN must 
> maintain state
>                        information.
> 
> SB> Why do we need the path oriented term? The network should
> SB> not have any idea that it is carrying a PW.
> 
>     Non-path-oriented PW
>                        A Non-path-oriented PW is a PW for which the
>                        network devices of the underlying PSN need not
>                        maintain state information.
> 
> SB> As above - why do we need it?
>
[Sasha] I concur with Stewart. 
>
>     Service Interworking
>                        In Service Interworking, the IWF (Interworking
>                        Function) between two dissimilar 
> protocols (e.g.,
>                        ATM & MPLS, Frame Relay & ATM, ATM & IP, ATM &
>                        L2TP, etc.) terminates the protocol used in one
>                        network and translates (i.e. maps) its Protocol
>                        Control Information (PCI) to the PCI of the
>                        protocol used in other network for 
> User, Control
>                        and Management Plane functions to the extent
>                        possible.
> 
>                        In general, since not all functions may be
>                        supported in one or other of the networks, the
>                        translation of PCI may be partial or 
> non-existent.
>                        However, this should not result in any loss of
>                        user data since the payload is not 
> affected by PCI
>                        conversion at the service interworking IWF.
> 
> SB> As this is out of scope, I suggest not cluttering up the 
> SB> definitions with it. Move it to the bottom where you define 
> SB> it out of scope.
>
[Sasha] I concur. 
>
>     Network Interworking
>                        In Network Interworking, the PCI 
> (Protocol Control
>                        Information) of the protocol and the payload
>                        information used in two similar networks are
>                        transferred transparently by an IWF of the PE
>                        across the PSN. Typically the IWF of the PE
>                        encapsulates the information which is 
> transmitted
>                        by means of an adaptation function and 
> transfers
>                        it transparently to the other network.
> SB> Same as above.
> 
> 
> 2.  Packet Processing
> 
>     This section describes forwarding plane requirements for PWE3.
> 
> 2.1.  Encapsulation
> 
>     Every PE MUST provide service interfaces for 
> encapsulating PDUs from
>     the PWESs.  It should be noted that the PDUs to be 
> encapsulated may
>     or may not contain L2 or L1 header information.  This is service
>     specific.  Every PWE3 service MUST specify what the PDU is.
> 
>     A PW header consists of all the header fields in a PW PDU that are
> 
> SB> Need to define PW header above?
> 
> <snip>
> 
> 2.4.  Segmentation and Reassembly
> 
>     It is desirable to avoid packet Segmentation and Reassembly (SAR).
>     One way to do this is to set the MTU of the links between 
> the CEs and
>     the corresponding PEs to a value smaller than (PW_Path_MTU -
>     PW_header - PSN_tunnel_header), if that is possible.
> 
> SB> Do we need the example, or just the requirement, and is it
> SB> sufficiently general to cover TDM?
>
[Sasha] IMHO SAR as defined applies only to emulation of L2 circuits,
[Sasha] because, among other things, there is no such thing as MTU 
[Sasha] for L1 circuits.
>
>     If SAR cannot be completely avoided, at a PW ingress, if 
> the length
>     of a packet resulted from encapsulation would exceed the 
> PW_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/L1
>     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.
> 
> <snip>
> 
> 2.6.  Consideration of PSN Tunnel Header Overhead
> 
>     In order to reduce PSN tunnel header overhead, multiple 
> PDUs MAY be
>     concatenated before a PSN tunnel header is added. Each PDU still
>     carries its own PW header so that the egress of the PW 
> knows how to
>     process it. However, the benefit of concatenating 
> multiple PDUs for
>     header efficiency should be weighed against the resulting larger
>     penalty incurred by packet loss.
> 
> SB> Do we need to do this for variable length packets?
> SB> This is unclear from the above.
> SB> I think that we should make clear that we really mean
> SB> cell like objects. Also there is a latency tradeoff. Is that
> SB>  important?
> 
[Sasha] I do not think that the text ebove really refers to concatention
[Sasha] of multiple ATM cells in a single PW packet (because in this case
[Sasha] there is only one PW header). Nor does it refer to concatenation
[Sasha] of multiple TDM-imposed structured ("frames") - for the same 
[Sasha] reason. And all the PW documents dealing with frame-oriented
[Sasha] payloads (FR, HDLC, Ethernet, ATM AAL5 SDU) explicitly state
[Sasha] that a single PW packet carries a single service frame.
[Sasha] So I do not see any use case for this kind of concatenation.
[Sasha] I suggest to drop it altogether.
> 
> 3.  Maintenance of Emulated Services
> 
>     This section describes control plane requirements for PWE3.
> 
> 3.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.
> 
>     Every PWE3 approach MUST define some setup mechanism for 
> establishing
>     the PWs. During the setup process, the PEs need to exchange some
>     information
> 
> SB> No exchange is manual case
> 
>     (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
> 
> SB> agree implies information exchange.
> SB> I think that you mean something like " both ends must operate
> SB> compatible methods....
> 
>     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 
> explicitly 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.
> 
> <snip>
> 
> 3.4.  Keep-alive
> 
> SB> I don't think the service needs to define a whole KA mechanism
> SB> it may be sufficient to carry the existing KA over the PW
> 
> <snip>
> 
> SB> Wow, you need to be very careful here. I think that if you
> SB> only have access to a TDM circuit, figuring how it got
> SB> across the PSN is pretty tough. It also breaks the transparancy
> SB> of the wire. This needs to be re-written or deleted.
> 
> <snip>
> 
> SB> not -> NOT
> SB> as high -> the same?
> 6.  Scalability
>     Scalability requirements for PWE3 are described below.
> 
>     - Only PEs should be aware of existence of PWs and PWE3 services.
>       Core network devices SHOULD NOT be exposed to a large number of
>       PWs.
> 
> SB> Why not? Surely its up to the SP what they want to do?
>
[Sasha] The WG Charter says: "PWE3 will not exert controls on 
[Sasha] the underlying PSN, but only function at the endpoints 
[Sasha] of the pseudo wire." To me, adding per-PW state to core 
[Sasha] network devices means a form of control over them.
[Sasha] Of course, it is up to the SPs to do what they want.
[Sasha] However, I would rather not call this PW.
> 
>       PWs can be path-oriented or non-path-oriented. For path-oriented
>       PWs, core network devices must maintain state 
> information for them.
>       If a large number of path-oriented PWs are used, core network
>       devices will have to maintain a large amount of state 
> information.
>       In order to avoid scalability problem, PSN tunnels 
> between PEs can
>       be introduced. PWs from the same ingress to the same egress are
>       nested inside the PSN tunnel that is from that ingress to that
>       egress. By creating such a tunnel hierarchy, individual PWs are
>       transparent to the core devices.  If a specific PWE3 
> approach uses
>       path-oriented PWs, PSN tunnels SHOULD be used to improve
>       scalability.  However, a PSN tunnel is not part of any PW.
>       Signaling of PSN tunnels NEED NOT be defined in the 
> PWE3 approach
>       itself. As an example, if LSPs are used as PWs in a 
> PWE3 approach,
>       they can be nested inside a tunnel LSP from the PW 
> ingress to the
>       PW egress.  The tunnel LSPs can be signaled by any mechanism
>       defined in [MPLS].
> 
> SB> I have a hard time with this path oriented stuff. It is equally
> SB> true that you do not have an infinate supply of IP addresses.
> SB> Perhaps what you meant to say is that the PW definition must
> SB> not consume excess network addressing resources.
> SB>
> 
>     - Circuit multiplexing: circuit multiplexing SHOULD be 
> supported (see
>       Section 2.1.3).
> 
>     - Collective status notification: collective status notification
>       SHOULD be supported.
> 
> 7.  Other Generic Requirements
> 
> 7.1.  RFC 2914 Conformance
> 
>     [RFC2914] describes the need for congestion control in 
> the Internet,
>     and discusses what constitute correct congestion control. Any PWE3
>     approach MUST conform to RFC 2914 and be TCP-friendly in 
> its response
>     to congestion. The applicability document of a PWE3 approach MUST
>     provide a statement on RFC 2914 conformance.
> 
> SB> There has certainly not been much thought given to this.
> SB> Does anyone have any idea how we do this with a TDM circuit?
> 
[Sasha] Yes, of course: there is simply NO WAY for a PW carrying 
[Sasha] a TDM circuit to be TCP-friendly. The text has to be changed
[Sasha] to accomodat this fact.
> 8.  Non-Requirements
> 
>     Some non-requirements are mentioned in various sections of this
>     document. Those work items are outside scope of the PWE3 WG.  The
>     non-requirements are listed below:
> 
>     - Service interworking;
> 
> SB> Please take this out of definitions above and define it here.
> SB> It seems silly to waste top level definition space with a non-goal
> 
>     - Selection of a particular type of PWs;
> 
>     - Striving to make the emulated services perfectly match 
> their native
>       services;
> 
>     - Defining mechanisms for signaling the PSN tunnels;
> 
>     - Defining how to perform traffic management on packets 
> that carry PW
>       PDUs;
> 
>     - Providing security for the PW PDUs;
> 
>     - Providing any multicast service that is not native to 
> the emulated
>       medium.
> 
>       To illustrate this point, Ethernet transmission to a multicast
>       IEEE-48 address is considered in scope, while multicast services
>       like [MARS] that are implemented on top of the medium are out of
>       scope;
> 
> SB> We seem to be delegating Ethernet multicast to the PPVPN group
> SB> who want to resolve the multicast at their level.
> SB> Is Ethernet multicast therefore still in scope?
> 
[Sasha] I would feel much bettwer with an explicit statement that
[Sasha] PWs are point-to-point. (IMHO this is what the network
[Sasha] reference model in the framework documents presents).
> <snip>
> SB> PW over IP cannot tell whether it's going over an AB or not.
> 
[Sasha] Of course it cannot. However if a PW runs in a PSN tunnel
[Sasha] that crosses multiple administrative domains, the SPs
[Sasha] managing these domains may be interested to prove 
[Sasha] (say, to the customer paying for the PW) that the PW has 
[Sasha] been carried faithfully within their domains. E.g., they
[Sasha] would probably want to be able to demonstrate that no
[Sasha] PW packets have been lost within a specific domain.
[Sasha] A similar mechanism in SONET/SDH is called Tandem Connection
[Sasha] Monitoring (TCM), and, AFAIK, some providers have really 
[Sasha] deployed it.
[Sasha] 
[Sasha] In addition, a "native hand-off" seeems out of scope to me
[Sasha] because it would result in multiple PWs (one per domain).
> 11.  Security Considerations
> 
> 11.1.  Security Considerations for Signaling/Control Channels
> 
>     If signaling/control channels are used in a PWE3 approach, some
>     security mechanism MUST be provided to ensure integrity of the
>     information transmitted across the signaling/control channels.
> 
> SB> Do you mean MUST?
> 
> 11.2.   Security Considerations for PW PDUs
> 
>     Providing security for PW PDUs is outside scope of the PWE3 WG.
> 
> SB> Do you mean MUST? The implication is that only IPsec can be used
> SB> for the IP tunnel.
>
[Sasha] And MPLS tunnels probably could not be used at all. I suggest
[Sasha] a weaker requirement. 
>
> 12.  Deployment Considerations
> 
>     Transition from using separate networks for TDM, ATM, 
> Frame Relay and
>     IP services to using a single network for multiple 
> services requires
>     careful planning and execution.  This is an important topic for
>     further study.
> 
> SB> I am not sure this section adds much value.
> 
>

---

From: Danny McPherson <[email-masked]>
Date: Thu, 03 Oct 2002 11:15:18 -0600

> - Ethernet private line services

Packet/Cell/Frame/Base
TDM (for lack of a more appropriate term?)

-danny

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 03 Oct 2002 21:29:08 +0200

Vach Kompella wrote:
> Once a packet belonging to a PW is handed to a tunnel, it becomes the
> responsibility of the tunnel to get it to the VC endpoint.  Now, a tunnel may
> not be nailed down (e.g., GRE).  So it is possible that the "actual path of the
> packets" is variable.  So I would say that finding the actual path of the
> packets itself can't be a MUST.
> 
> On the other hand, can we say that there MUST be a mechanism for determining the
> path a packet takes?  To a large extent, it depends on what the tunnel itself is
> that carries the PW's packets.  Is there a traceroute for every tunnel type?
> 
> For p2p PWs:
> GRE -> traceroute
> MPLS -> lsp-ping's traceroute
> L2TP -> traceroute (but not good enough)
> L2TPv3 (aka UTI) -> traceroute (but not good enough)

What specific deficiencies in traceroute are you referring to that exist with 
L2TP and L2TPv3 (and thus being labeled as "not good enough") that do not exist 
with GRE (which somehow avoids this title)?

> 
> For hierarchical VPLS, there's a traceroute that hops across the PWs that are
> stitched together to determine the path.  The tunnels for the individual PWs
> also can be tracerouted as in the p2p PWs.
> 
> So except for being unable to foresee what other tunnel types may exist (which
> may not have traceroute capability), and that the dependence on the tunnel
> having a traceroute capability may be out of scope for PWE3, what is the problem
> with saying MUST?
> 
> -Vach
> 
> 
>>From: [email-masked] [mailto:[email-masked]]On Behalf Of Eric
>>Rosen
>>Sent: Thursday, October 03, 2002 10:12 AM
>>To: Peter Willis
>>Cc: [email-masked]
>>Subject: Re: [PWE3] Comments on draft-ietf-pwe3-requirements-03.txt
>>
>>
>>
>>Peter> "there MUST  be a mechanism  for an operator  to find out  the actual
>>Peter> path  of the  packets  carrying the  PW and  the  path of  the PW  as
>>Peter> determined by the control plane"
>>
>>I think that's too  strong, as it is not clear that  this requirement can be
>>met in any feasible manner.

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 3 Oct 2002 12:57:42 -0700

I guess I don't know enough about L2TP, so I may be wrong, but I don't think
that just saying that a UDP packet can get from A to B implies that an L2TP
session (tunnel) can get packets from A to B.  I thought there was more to an
L2TP "session" than simple IP connectivity?

GRE tunnels don't presume anything more than IP connectivity.

-Vach

> From: W. Mark Townsley [mailto:[email-masked]]
> Sent: Thursday, October 03, 2002 12:29 PM
> To: [email-masked]
> Cc: [email-masked]; Peter Willis; [email-masked]

---

From: "Vach Kompella" <[email-masked]>
Date: Thu, 3 Oct 2002 12:58:42 -0700

Lloyd,

Not sure what the distinction you are making is - classic vs. ?

-Vach

> From: Lloyd Wood [mailto:[email-masked]]
> Sent: Thursday, October 03, 2002 11:20 AM
> To: Vach Kompella
> Subject: RE: [PWE3] Comments on draft-ietf-pwe3-requirements-03.txt 
> 
> 
> On Thu, 3 Oct 2002, Vach Kompella wrote:
> 
> > responsibility of the tunnel to get it to the VC endpoint.
> 
> I presume you're talking about classic tunnel decap here.
> 
> Is that correct?
> 
> L.
> 
> <http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>
>

---

From: "W. Mark Townsley" <[email-masked]>
Date: Thu, 03 Oct 2002 22:38:41 +0200

> GRE tunnels don't presume anything more than IP connectivity.

GRE presumes IP reachability _and_ proper, deliberate, configuration of two PEs. 
This PE configuration must either be entered by a human or a network management 
system of some kind in order for the GRE tunnel to "exist". You need even more 
configuration (e.g. a Key) entered at each PE if you use GRE for L2VPNs, as I 
would suspect that you would want some ability to carry more than a single 
pseudowire between two like IP addresses.

Similarly, L2TPv3 presumes IP reachability and proper configuration at both PEs. 
That configuration may be tediously entered manually as it would with GRE, or 
ephemeral portions generated and exchanged via a PE to PE signaling protocol.

Referring to the PWE3 architecture, the "Tunnel" in L2TPv3 refers literally to a 
simple pair of PE IP addresses. Pseudowires then reside within this "tunnel" as 
L2TP sessions.

Aside, perhaps, of generic per-hop IP load-balancing that may or may not be 
present in a given network, all data for L2TP sessions (together with the 
control protocol for setting up the sessions) take the same IP path as that of 
the underlying tunnel. Thus, ping and traceroute can be used as effective 
measures of L2TPv3 tunnel integrity inasmuch as they are relied upon today for 
reachability of any two nodes or path through an IP network.

- Mark

>>>responsibility of the tunnel to get it to the VC endpoint.  Now, a
>>
>>tunnel may
>>
>>>not be nailed down (e.g., GRE).  So it is possible that the "actual
>>
>>path of the
>>
>>>On the other hand, can we say that there MUST be a mechanism for
>>
>>determining the
>>
>>>path a packet takes?  To a large extent, it depends on what the
>>
>>tunnel itself is
>>
>>>For hierarchical VPLS, there's a traceroute that hops across the
>>
>>PWs that are
>>
>>>So except for being unable to foresee what other tunnel types may
>>
>>exist (which
>>
>>>having a traceroute capability may be out of scope for PWE3, what
>>
>>is the problem
>>
>>>with saying MUST?
>>>
>>>-Vach
>>>
>>>
>>>

---

From: [email-masked]
Date: Fri, 4 Oct 2002 15:40:36 +0100

Thomas D. Nadeau wrote 03 October 2002 14:56
> At 09:08 AM 10/3/2002 +0100, [email-masked] wrote:
> >Thomas D. Nadeau wrote 02 October 2002 20:40
> >
> ><snipped>
> > >          Given the operational requirements that I have seen,
> > > it is paramount for deployment of services to have a tracing/ping
> > > function before these folks will deploy PWs in their networks.
> > > I would be okay to change "MUST" to "SHOULD" if that would
> > > make you happy.
> >NH=> The operations requirements don't specifically ask for 
> trace-route or
> >LSP-Ping.....that is your interpretation.
> 
>          Right, they ask for a tracing function and a 
> "connection verification
> mechanism.  We should probably use the terms "connection verification"
> and "connection tracing".
NH=> When you came to see us in this context, the hot issue was
fault-management of VPNs when *LDP* is used....it was nothing to do with PWs
or the XoverMPLS network-interworking functional convergence case.  We have
no deployments of PWs or XoverMPLS as yet as you know and I thought we
agreed that (looking ahead to this) Y.1711 provides a very simple solution
for automatic detection/handling in such a case.  So I think you are stating
operator's requirements to fix LDP in a L3 VPN case only and not the PW
case....so can you clarify which issue you are stating the operators
requirements (you have seen) are for?  Its not at all clear to me why one
would use LDP for XoverMPLS anyway.  
> 
> >Operations people now want to
> >able to manage the technoloogy they have been sold that came 
> without any
> >such fault-management tools.
> 
>          Lets not exaggerate.
NH=> I am not exaggerating, this is a fact.  As you said yourself you are
getting this message loud and clear from operators now.

> Most devices come with at least
> some fault-management tools.
NH=> And some technologies are properly specified before
release.......though I hestitate to say a good job is always done.  There is
big difference IMO developing technologies for the public Internet and
selling solutions to operators for commercial use.   Paying customers don't
like operators to use them as technology guinea pigs.  In all the external
assessments I have read, fault-management (of VPNs) seems to come at the top
of the pile of things that need urgent attention (and please remember we
tried really hard to get everyone to think more about this way back when
many said its not an issue....and one vendor who I shall not name, but you
know them well, even suggested going to another vendor if their box was no
good, not fixing the missing OAM).  Does not the fact that you are taking
this subject more seriously now also reflect this?

> which is in essence LSP Ping.
NH=>Not at all.  LSP-Ping is IMO a complex 2-way function, CV in Y.1711 is a
simple 1-way function because defect handling has to be a simple 1-way
function in CO networks, and trails/paths/LSPs are 1-way functions.  CV is
fully specified (wrt defect entry/exit/consequent actions etc) LSP-Ping has
none of this.  CV is agnostic of signalling used or client supported in p2p
case.  The key issue here is not this aspect anyway but LDP, and the fact
LDP creates mp2p constructs....its is the fault-management of these
constructs that is at question here (which is not really an issue for PWs
IMO so I'm not even sure why you jumped in on this thread in the 1st place).

>  As you know, the original part of that
NH=>I know you meant 'LDP-signalled LSPs'......but Tom have you actually
read LSP-Ping?  If not please do so.  Given about a year as gone by since I
last read I thought I should check it out hoping to find it complete by now.
It's not.  Its got more complex *and* it still excludes LDP!  There are also
lots of caveats and areas not complete (indeed some cannot be complete, like
correct fault indication mappings to non-IP clients in XoverMPLS cases).  If
I compare this with something like y.1711 + another solution I have just
been reading which will be proposed soon for the specific LDP case (and that
is very simple too, like Y.1711) I know which solutions I'd go for.
However, that's just my view and other should read things like LSP-Ping and
make their own minds up.
> 
>          --Tom
> 
> 
> >and you cannot get any simpler than that as you ought to know.  LDP
> >is the problem.....though what real *operators network 
> problem* LDP solves
> >that is not better solved by a pure IP solution beats me...I 
> have asked this
> >question loads of times and I can't find anyone who can 
> answer it.  However,
> >given the nature of the beast and that its out there, I 
> would not want to
> >preclude other solutions for the network management 
> headaches LDP mp2p
> >constructs create .....indeed I have just been looking at 
> one such proposal.
> >
> >regards, Neil
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 04 Oct 2002 11:19:44 -0400

>would use LDP for XoverMPLS anyway.

         I have seen operational requirements for L2 and L3 VPNs that
are quite similar as a matter of fact. Verification of the reachability and
tracing between PEs (sometimes automated) is certainly at the top of that 
list,
and in the L2 case, verification of those things for the VC itself.  As is 
doing
this in a simple and scalable manner.

> > without any such fault-management tools.
> >
> >          Lets not exaggerate.

         I think we need to be precise. I have definitely not gotten the 
message
from anyone but yourself that "... the technology they have been sold that 
came
without any such fault-management tools."  Certainly no products or standards
are perfect, but I think your statement is quite misleading and could  not be
further from the truth when you say that (MPLS) products are generally shipped
today without any fault-management tools.  Even in the case of PWE/VPN MPLS
products, I think this statement is not true, as most products I know of 
today are
shipped with at least some functions in this area. Perhaps these solutions 
are not
perfect, but vendors are working to make them better.

         Back to the original thread from which we have diverged too far 
already.
The message I am getting with regard to PWE3 OAM is that CV and tracing 
between
PEs and PW VC endpoints are very important.  I think the text I suggested 
for the
requirements draft yesterday covers this.

         --Tom

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 4 Oct 2002 08:55:17 -0700

What I was talking about (and what I thought the conversation was about) was the
path the packet follows in the emulated side, i.e., in the provider network.  It
is the tunnel's responsibility to get a PW packet from one end of the PW to the
other.  In that case, a traceroute for the tunnel determines the path of PW
packets.

Again, I say nothing about the guarantee a tunnel makes, just that there's a
handoff at one endpoint of the tunnel, and the PW knows nothing until the tunnel
gets the packet to the other end.

-Vach

> Sent: Friday, October 04, 2002 4:32 AM
> To: Vach Kompella
> are we talking about the decap side here, and passing the PW-PDU
> content to the VC endpoint?
>
> At encap side, the tunnel entry point can't be responsible for
> delivery by the PSN - we're not building reliable tunnels.
>
> (so classic: encap/decap tunnel functions, nothing more.)
>
> L.
>

---

From: "Vach Kompella" <[email-masked]>
Date: Fri, 4 Oct 2002 09:05:55 -0700

Mark,

We are talking about PWs over a GRE encap.  The PWs carry a "key", the inner
label, already.  We are just using the MPLS in GRE encap.  So there's no tunnel
session.

Suppose I want to use L2TP as the transport tunnel between A and B, are you
suggesting a completely different encap, i.e., not the
draft-ietf-pwe3-ethernet/fr/atm/etc encap?  (I haven't really been keeping up
with the L2TP discussions, so forgive the question.)

But I was assuming that the encap for the PW would be the same, and the inner
label would be the discriminator.  If that is the case, then what I said stands:
just because you can get IP-wise from A to B doesn't mean you can get there
through an L2TP tunnel.  So I suppose what I was really talking about is CV not
traceroute.

-Vach

> Sent: Thursday, October 03, 2002 1:39 PM

---

From: "W. Mark Townsley" <[email-masked]>
Date: Fri, 04 Oct 2002 19:06:48 +0200

> with the L2TP discussions, so forgive the question.)

L2TP has its own pseudowire identifier -- it does not use the MPLS label format 
for this (and why should it?).

> But I was assuming that the encap for the PW would be the same, and the inner

The L2 framing would be the same, e.g. carrying the ethernet header in its 
entirety and such. But from the PW identification down, it's different. Since 
L2TP's roots are not in MPLS, it doesn't look like MPLS. Please read 
draft-townsley-pwe3-l2tpv3-00.txt if you would like an overview.

> through an L2TP tunnel.

As I said before, a PWE3 tunnel in L2TP is just a pair of PE IP addresses. The 
L2TP sessions are the individual PWs, much like the MPLS label and associated 
directed LDP sessions are for MPLS over GRE. So, if you are just concerned about 
the "health" of the tunnel, you can use IP tools to determine that. If you are 
concerned about the health of the PW (session), you need L2TP tools. Our 
experience with L2TPv2 tells us that the control plane and associated Hello 
mechanism covers some of the bases here (I think enough to satisfy the text 
proposed by Thomas yesterday), though there could naturally be room for 
improvement as we deploy in different environments.

So, if ping/traceroute is good enough for MPLS over GRE to test the status of 
the GRE tunnel, it certainly is for testing the status of the L2TP tunnel. They 
are, after all, the same thing. Just a pair of PE IP addresses.

- Mark

 > So I suppose what I was really talking about is CV not
> traceroute.
> 
> -Vach
> 
> 
>>>session (tunnel) can get packets from A to B.  I thought there was
>>
>>more to an
>>
>>>>>that carries the PW's packets.  Is there a traceroute for every
>>
>>tunnel type?
>>
>>>>>For p2p PWs:
>>>>>GRE -> traceroute
>>>>What specific deficiencies in traceroute are you referring to that
>>
>>exist with
>>
>>>>>stitched together to determine the path.  The tunnels for the
>>
>>individual PWs
>>
>>>>>>Peter> "there MUST  be a mechanism  for an operator  to find out
>>
>>the actual
>>
>>>>>>Peter> path  of the  packets  carrying the  PW and  the  path of
>>
>>the PW  as
>>
>>>>>>I think that's too  strong, as it is not clear that  this
>>
>>requirement can be
>>

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Oct 2002 10:45:50 -0700

Thom,

> this in a simple and scalable manner.

I think what Neil was pointing out was not that you don't need CV
or tracing for L2VPN and PWE3. He was simply pointing out that
p2p LSPs could use Y.1711 (as is) and you can't get any simpler than
that.

For the mp2p (i.e., LDP-based such as RFC2547) case you could probably use MPLS-ping,
but what Neil pointed out was that L2VPN and PWE3 are not using LDP-based LSPs as the transport LSPs anyway, rather they use ER-LSPs. So the problem that you are faced
to solve is not L2VPN or PWE3 OAM, as these problems have already been solved by
a simple mechanism (Y.1711).

> perfect, but vendors are working to make them better.

Could you please share some of those functions with us?
are they proprietary functions?

> PEs and PW VC endpoints are very important.

That is correct, and Y.1711 already solves those problems for PWE3 with
the simplest possible approach.

Yours,
-Shahram

---

From: Eric Rosen <[email-masked]>
Date: Fri, 04 Oct 2002 13:57:55 -0400

Shahram> L2VPN and PWE3  are not using LDP-based LSPs  as the transport LSPs
Shahram> anyway 

Wrong.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Oct 2002 11:16:38 -0700

Although I wonder about the benefits of using LDP-based LSPs as the
transport LSP (why not just use IP) for the L2VPN/PWE3, but even if one wants to
do it, the inner PW-LSPs are built on a p2p (remote peering) basis, 
and therefore they can still use Y.1711. The point is that
a good solution already exist for L2VPN/PWE3. I think it
would be better to focus on a more important deployed area
that lacks OAM function and that is L3VPN (RFC2547).

-Shahram

> From: Eric Rosen [mailto:[email-masked]]
> Sent: Friday, October 04, 2002 1:58 PM
> To: Shahram Davari
> Cc: 'Thomas D. Nadeau'; [email-masked]; [email-masked]
> Subject: Re: FW: [PWE3] comments on 
> draft-ietf-pwe3-requirements-03.txt 
> 
> 
>

---

From: Eric Rosen <[email-masked]>
Date: Fri, 04 Oct 2002 14:46:45 -0400

> the inner PW-LSPs are built on a p2p 

In fact, the inner  LSPs are not only p2p, they are  also only one hop long,
which certainly makes it easy to do the traceroute function!

If what you  are trying to verify is  whether data can be carried  on the PW
between the ingress PE and the egress  PE, then it's the tunnels you want to
verify, not the PWs.  Certainly if you  want to know how far the packets get
(i.e., traceroute), you need a tunnel-based test mechanism, because pw-based
mechanisms  won't  be  visible  in  the  core.  (I  guess  you  could  do  a
tunnel-based mechanism on  a per-PW basis, if you  don't mind having several
order of magnitude of unnecessary overhead.)

Verifying the individual  PWs is useful if it allows you  to verify that the
ingress is properly encapsulating the customer's frames, and that the egress
is properly decapsulating  and disposing of those frames.   This requires an
edge-to-edge test mechanism  (i.e., ping) that will pass  the frames through
the NSP and Forwarder layers as well as through the PW.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Oct 2002 12:43:36 -0700

And why is LDP-based LSPs better than IP tunneling for PWE3?
As opposed to L3VPN, this time around hopefully the spoofing
won't be an issue (since the payload is not IP any more)!

-Shahram

> Sent: Friday, October 04, 2002 2:47 PM
> To: Shahram Davari

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 04 Oct 2002 15:47:31 -0400

>And why is LDP-based LSPs better than IP tunneling for PWE3?

         It isn't. The point is that a lot of people are using it, so it
is a very common case that needs to be handled.

         --Tom

---

From: Eric Rosen <[email-masked]>
Date: Fri, 04 Oct 2002 16:03:42 -0400

Shahram> And why is LDP-based LSPs better than IP tunneling for PWE3? 

For a number of reasons, but I  don't think this has anything to do with the
topic under discussion.  By the way,  there is no fundamental reason why you
couldn't have merging of explicitly routed LSPs.

Shahram> As opposed to L3VPN, this  time around hopefully the spoofing won't
Shahram> be an issue (since the payload is not IP any more)! 

Insofar as one  might be worried about spoofing, the type  of the payload is
irrelevant.

---

From: Shahram Davari <[email-masked]>
Date: Fri, 4 Oct 2002 13:42:01 -0700

> topic under discussion.  

I think it does. If it is found that LDP is not the appropriate technology
for PWE3, then its OAM should not be discussed in PWE3 WG. 

>By the way,  there is no fundamental 
> reason why you

First of all nobody uses it. Secondly, Y.1711 still works in merged ER-LSPs.

> Insofar as one  might be worried about spoofing, the type  of 

So what is important for spoofing? If you are not doing IP transport, how can
you spoof?

-Shahram

---

From: [email-masked]
Date: Fri, 4 Oct 2002 22:42:19 +0100

What do mean by 'wrong' Eric?  Do you mean Shahram is wrong because:
A	that's what we gave you all so be grateful and get on and use it
because you have no choice now?
B	that's the right solution for our industry for these sound technical
reasons x, y, z?

I have never seen *any* good justification for LDP for any real networking
problem...and I have asked several times for an answer to this.  There seem
to be an awful lot of people I know who are scratching their heads to come
up with some justification....and all the scratching has done so far is
throw up more problems (though practically, having now been given it, many
these poor souls just want to be able to manage it).  Real cnls IP solutions
look good to me and so do real co p2p LSP solutions.  1/2-way house LDP
solutions seem to raise more negatives than plusses.

My experience so far tells me A is the correct answer and we have it because
that is what we were given as pushed by a certain large router vendor.  But
maybe I and many others are just simply too stupid to grasp the benefits we
are missing.  

So perhaps I am simply lacking in my education.  Perhaps Juha (if he is
reading this) might enlighten us why he seems not to favour LDP too?

regards, Neil

> Sent: 04 October 2002 18:58
> To: Shahram Davari

---

From: [email-masked]
Date: Fri, 4 Oct 2002 22:42:22 +0100

Why do you think it is so common Tom?....what's so compelling in its favour?

regards, Neil

> From: Thomas D. Nadeau [mailto:[email-masked]]
> Sent: 04 October 2002 20:48
> To: Shahram Davari
> Cc: [email-masked]'; [email-masked]; [email-masked]
> Subject: RE: FW: [PWE3] comments on

---

From: Eric Rosen <[email-masked]>
Date: Sun, 06 Oct 2002 21:26:58 -0400

Shahram> If it is found that LDP is not the appropriate technology for PWE3,
Shahram> then its OAM should not be discussed in PWE3 WG.

Any  tunnel-specific  OAM would  not  be  under  the jurisdiction  of  PWE3,
certainly. I believe  also that the choice of control  protocols used to set
up the tunnels  is outside the jurisdiction of PWE3.  So  the whole issue of
whether LDP is a good control protocol for setting up tunnels is outside the
jurisdiction of PWE3. 

Shahram> If you are not doing IP transport, how can you spoof?

The ease or difficulty of  spoofing depends on the tunneling technology, not
on the type of the payload carried within the tunnel.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 08:34:46 -0700

> certainly. 

And therefore no requirement for the tunnel tracing should be in PWE3.

> on the type of the payload carried within the tunnel.

I am sorry to say that it depends on both the tunnel technology and the payload.

 -Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 11:48:48 -0400

>And therefore no requirement for the tunnel tracing should be in PWE3.

         I disagree. From the context of PWE3 it is a
requirement to be able to trace the transport
tunnel path(s).

         --Tom

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 08:53:12 -0700

I disagree. From the PWE3 point of view, it is enough to know that the
packet has arrived at egress PE. The details trace through the network is outside
of PWE3 scope as is the tunnel OAM and signaling.

-Shahram

> Sent: Monday, October 07, 2002 11:49 AM
> To: Shahram Davari
> >I am sorry to say that it depends on both the tunnel 
> technology and the 
> >payload.
> >
> >  -Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 12:12:07 -0400

The fact that the tracing is actually done on
the underlying tunnel does not obviate the
requirement for tunnel tracing capability from the
perspective of the PW.   If there is no requirement
from the PW to have tracing functions from
the underlying tunnel, then tunneling technologies
can be applied to PWs that do not provide
tracing functions, and thus will not meet the need
from the PW's perspective. Therefore, it is necessary to
leave this as a requirement.

         --Tom

---

From: Danny McPherson <[email-masked]>
Date: Mon, 07 Oct 2002 10:15:01 -0600

> requirement to be able to trace the transport

Folks, please note that our charter specifically states that we 
will define "Common Edge-to-Edge Emulation/Maintenance Protocol 
requirements for PW Traceroute *(if distinct from tunnel-specific 
or CCAMP traceroute)*.

-danny

---

From: Sasha Vainshtein <[email-masked]>
Date: Mon, 7 Oct 2002 18:34:14 +0200

Tom, Shahram and all,
Following Tom's last message, I suggest the following
text:

"Tunneling technologies used for the PWE3 purposes MUST
support tracing".

Would it be OK?
With best regards,
                                   Sasha Vainshtein

> Sent: Monday, October 07, 2002 6:12 PM
> To: Shahram Davari
> Cc: [email-masked]
> >packet has arrived at egress PE. The details trace through 
> the network is 
> >outside

---

From: Eric Rosen <[email-masked]>
Date: Mon, 07 Oct 2002 12:40:39 -0400

Eric> The  ease   or  difficulty  of  spoofing  depends   on  the  tunneling
Eric> technology, not on the type of the payload carried within the tunnel.

Shahram> I am sorry to say that it depends on both the tunnel technology and
Shahram> the payload.  

By a  "spoofed packet", I  mean a packet  that looks just like  a legitimate
tunneled packet (e.g., an IP packet containing a frame relay payload), where
the  IP header  was not  put on  by a  legitimate tunnel  ingress.   To send
spoofed packets to the backbone, all that is required is that there be an IP
interface (unprotected  by filters) to the  backbone over which  they can be
sent.

So I don't see what the payload type has to do with it.

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 09:52:48 -0700

Spoofing means illegitimate access by customers, not failure of SP's ingress routers.
All non-IP traffic will be tunneled without the need for filters, so there is no chance for spoofing.

-Shahram

> Sent: Monday, October 07, 2002 12:41 PM
> To: Shahram Davari

---

From: Danny McPherson <[email-masked]>
Date: Mon, 07 Oct 2002 11:04:51 -0600

> failure of SP's ingress routers.

Or Peers...  And source-address verification of packets 
received from peers in large networks is pretty much 
unthinkable with deployed (and "next-gen") hardware...

-danny

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 13:08:05 -0400

> >          The fact that the tracing is actually done on the
> > underlying tunnel does not obviate the requirement for tunnel
> > tracing capability from the perspective of the PW.  If there is no
> > requirement from the PW to have tracing functions from the
> > underlying tunnel, then tunneling technologies can be applied to PWs
> > that do not provide tracing functions, and thus will not meet the
> > need from the PW's perspective. Therefore, it is necessary to leave
> > this as a requirement.
>
>
>Let me see if I understand the above correctly.
>
>You are demanding an unnecessary requirement because, if you don't
>demand it, this unnecessary requirement will be considered unnecessary
>and then you can't demand it.

         If you understand the point of a requirements document, it is of
course to stipulate requirements, not new functions. I am not proposing
that we define redundant functions for PWE traceroute, all I am
reporting is that my customers are demanding tracing/ping functions
on whichever tunneling transport is used.  If they are defined already
for all existing transport types, then our work is done. If not, then we
either need to fix the transport types or define our own tracing/ping
functions. This is what the statement I suggested last week says; no
more, no less.

>Where you == the PW perspective, of course.

         Oh give me a break already.

         --Tom

---

From: Eric Rosen <[email-masked]>
Date: Mon, 07 Oct 2002 13:11:25 -0400

Shahram> Spoofing  means  illegitimate  access  by  customers.   All  non-IP
Shahram> traffic will be tunneled without  the need for filters, so there is
Shahram> no chance for spoofing.  

It's true  that you can't use a  non-IP interface for spoofing.   As long as
the SP  has any IP  interfaces to any  customers, spoofed packets  can enter
over those interfaces unless there is proper filtering.

---

From: [email-masked]
Date: Mon, 7 Oct 2002 18:09:38 +0100

Tom,
> perspective of the PW.
NH=> No, tracing must be from the perspective of the layer considered and
*not* its client.  See my previous mail for why.

   If there is no requirement
> leave this as a requirement.
NH=> Anyone can use any old clinet/server encapsulation
relationships....there are (unfortunately I think) no laws that stop this.
Now some relationships make far more sense than others.  However, the mere
fact tunneling technology X is inferior to tunneling technology Y is
irrelevant in respect of what is being discussed.  If that it the case it's
a drop-off of those specifying technology X.  Case of 'buyer beware' I
think.

---

From: [email-masked]
Date: Mon, 7 Oct 2002 18:09:39 +0100

Correct.  I agree with Eric and Shahram on this.  Layer independence is the
key....tracing (or indeed any invasive probing) below PW layer is pertinent
only to the lower layer.  You may not even *own* the lower layers if leasing
capacity....so you won't even be allowed to trace that.  Further, 'link
connections at layer N = trail connections at layer N+1'....this
relationship recurses to the duct.  So where does one stop saying  'I am
allowed to trace, etc'?

regards, Neil

> From: Shahram Davari [mailto:[email-masked]]
> Sent: 07 October 2002 16:53
> To: 'Thomas D. Nadeau'
> the network is outside

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 7 Oct 2002 13:17:44 -0400

Tom,

	You are asserting that it is a requirement to 
be able to trace transport tunnel paths.  Sorry to
have missed this if it was explained earlier, but 
why is it a requirement?

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> Subject: RE: FW: [PWE3] comments on draft-ietf-pwe3-requirements-03.txt
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 10:15:28 -0700

Having an IP-interface to the customer is not sufficient
for spoofing, SP also needs to offer IP (Internet service) 
service. If the service is PWE3, there is no way the customer can spoof.

-Shahram

> Sent: Monday, October 07, 2002 1:11 PM
> To: Shahram Davari

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 13:33:12 -0400

>have missed this if it was explained earlier, but

         Troubleshooting.

         --Tom

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 13:48:56 -0400

>only to the lower layer.

         Specification of the actual tracing function on the
underlying tunnel (LSP/TE tunnel/L2TP session)
is independent of the PW, agreed.  The point is that one needs
to exist that can be invoked by what you refer to as the
"client layer", which is why it belongs in the requirements for
PWs.

>You may not even *own* the lower layers if leasing

         Why don't you think that it is reasonable to assume that the provider
that owns the core network over which the PWs are run will also own the
underlying LSPs or L2TP tunnels too?

         --Tom

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 7 Oct 2002 20:00:16 +0200

> PDH and SDH are slightly more precise terms than the generic term TDM.

PDH and SDH are too precise, in fact they don't cover E1 and T1.
 
Y(J)S

Yaakov (Jonathan) Stein        [email-masked] 
Chief Scientist                      +972 3 6455389   +972 2 5889159
RAD Data Communications   24 Raoul Wallenburg St., Tel-Aviv 69719, Israel

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 7 Oct 2002 14:03:33 -0400

Tom,

	Because of the concept of "Carrier of Carriers".

Eric W. Gray
Systems Architect
Celox Networks, Inc.
[email-masked]
508 305 7214

> ---
> [snip]
> 
>          Why don't you think that it is reasonable to assume
> that the provider that owns the core network over which the 
> PWs are run will also own the underlying LSPs or L2TP tunnels 
> too?
> 
>          --Tom
> 
> 
>

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 11:03:01 -0700

For a PW service, all that is required, is to know that
the PW ends up at the correct PE/Interface. If it does not,
then another transport-tunnel could be used to deliver
the PW to the proper egress. 

How the SP localizes and repairs the first transport-LSP, which may require
transport-LSP traceroute, should be irrelevant to the PW.

-Shahram

> Sent: Monday, October 07, 2002 1:49 PM
> To: [email-masked]
> Cc: Shahram Davari; [email-masked]; [email-masked]
> that the provider

---

From: Danny McPherson <[email-masked]>
Date: Mon, 07 Oct 2002 12:06:58 -0600

Yes, I think we we're aiming for "generic" here...

-danny

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 14:13:31 -0400

>transport-LSP traceroute, should be irrelevant to the PW.

         It may be important that the feature exist on the underlying
tunnel so that the SPcan trace if they want/need to use it.

         --Tom

---

From: "David Allan" <[email-masked]>
Date: Mon, 7 Oct 2002 14:14:09 -0400

IMHO the real issue is that transport tunnels require maintenace procedures,
and this is not unique to transporting PWs.

Putting this in a PW requirements document is somewhat akin to legislation
on ignorance ;-) How 'bout a BCP?

cheers
Dave

> Sent: Monday, October 07, 2002 2:03 PM
> To: 'Thomas D. Nadeau'; [email-masked]
> Cc: [email-masked]; [email-masked]
> > > > > > > The ease or difficulty of  spoofing depends on 
> the tunneling
> > > > > > > technology, not

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 11:17:36 -0700

SPs also need statistics, MIBs, control-plane, signaling,
addressing, etc for the transport-tunnel, why don't we also
add those to the PWE3 requirements?

-Shahram

> Sent: Monday, October 07, 2002 2:14 PM
> To: Shahram Davari
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 14:20:14 -0400

That is one case, and I understand that tracing
is probably nearly impossible in a CsC scenario.  Point is that
this should behave just like it does today with IP: just another
empty hop in the trace if the provider does not want to respond
to ping, but the part of the trace that goes over the provider network
that can respond will.  Also, what about the other cases where they
do own the core (which seems to be more typical case today anyway)?

         --Tom

---

From: "Yaakov Stein" <[email-masked]>
Date: Mon, 7 Oct 2002 20:38:32 +0200

> Yaakov
> 
> Please, give me a clue, what term would you use?
> 
> Stewart :)
> 

Stewart, 

If you want to be completely generic - 
then say "synchronous bit-stream"
(which is close to the term you used in 
you original "layering" slides).

This covers n*64, full E1/T1, PDH, SDH, 
but also X.21, V.35, etc.

If you want the restriction to internationally defined (i.e. G.702) rates 
and standardized alarms,  then stick to "TDM".

Y(J)S

---

From: [email-masked]
Date: Mon, 7 Oct 2002 19:50:13 +0100

Hi Tom,

<snip> 
> underlying LSPs or L2TP tunnels too?
NH=>This may be a reasonable assumption in some cases and a
restrictive/unreasonable assumption in others.  However, what we need are
general solutions for all cases.  And this is why I keep banging on about
the need for layer independence when we view these requirements.  If one
adopts the right model from the outset one can cater for all cases....and
that's what I am shooting for.
regards, Neil

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 14:58:50 -0400

>that's what I am shooting for.

         Requiring that the underlying "tunnel" offer tracing and
CV functions is as general as it gets.

         --Tom

---

From: [email-masked]
Date: Mon, 7 Oct 2002 20:03:48 +0100

E1 and T1 belong to PDH and only PDH.

regards, Neil

> From: Yaakov Stein [mailto:[email-masked]]
> Sent: 07 October 2002 19:00
> To: bob.barrett; stbryant
> Cc: pwe3
> Subject: RE: [PWE3] comments on draft-ietf-pwe3-requirements-03.txt
> 
>

---

From: [email-masked]
Date: Mon, 7 Oct 2002 20:03:50 +0100

OK...good point....but simpler way of saying is 'layer independence is
required please'.  This is the (only arch clean) way to approach all of
this.

regards, Neil

> Sent: 07 October 2002 19:18
> To: 'Thomas D. Nadeau'
> > > > > > > >And therefore no requirement for the tunnel 
> tracing should
> > > > > > > be in PWE3.
> > > > > > >

---

From: [email-masked]
Date: Mon, 7 Oct 2002 20:03:52 +0100

I don't buy/like these specific 'own to the duct' cases.  It may apply in
some cases but not all.....solutions should cater for the general case.
This was also the big problem with the GMPLS mind-set IMO.  Networking life
is not like this and never will be.  There are commercial requirements to be
met for both client/server (aka tunelling) and peer-peer (at NNIs).  The
*technical* solutions must understand/respect these commercial
relationships....this is how we work.

regards, Neil

> Sent: 07 October 2002 19:20
> To: Gray, Eric
> Cc: [email-masked]

---

From: [email-masked]
Date: Mon, 7 Oct 2002 20:21:24 +0100

Tom,

I don't disagree with you wrt requirements, ie an ability to fault-manage a
given layer network.....but I do disagree if you believe its the client
layer's divine right to peer into and dictate what happens in the server
layer.  Not only is this a technical layer violation (with all that that
entails wrt independent protocol development), but commercially I am trying
to point out it has no validity in the real world general case......SPs
lease lower layer capacity where we don't have owned infrastructure of our
own.  If we keep the arch clean, by applying the rules of layer
independence, these are non-issues.  That is, if the tools are not built
into the server layer that is a deficiency of the server layer alone.
Further, when one wants arbitrary client/server relationships (for
flexibility...and I am ignoring the fact that some client/server
relationships are more logical than others) then this  line of reasoning is
so obviously right I can't honestly see why it should even be questioned.

regards, Neil

> Sent: 07 October 2002 19:59
> Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 15:28:06 -0400

>given layer network.....

         Then I think that we are in violent agreement on this point.  Lets 
just
add the lines to the requirement document to this effect and move forward.

         --Tom

>but I do disagree if you believe its the client
>layer.
>Not only is this a technical layer violation (with all that that

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 12:54:41 -0700

There is no need to have any fault management requirement for
the transport-LSP in the PWE3 requirements draft. The reason
is not that it is not required, but because it is irrelevant to
PWE3.

This is like requiring that for a specific mail service
(let's say premium) the Postal service company MUST have a
tool to detect the exact route that a package has taken. 
A customer does not care about that, and a Postal
Service company that wants to stay in business, has it regardless
of the service type.

-Shahram

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 07 Oct 2002 16:11:34 -0400

>is not that it is not required, but because it is irrelevant to

         How is the tracing requirement irrelevant to PWE3?
You said yourself above that fault-management is required by
PWs.  Fault management includes a tracing function.
What that is and how it is implemented for the underlying
tunnel is what is irrelevant to PWE3; the point is that it exists for
whatever underlying tunnel.  This statement says nothing about
who it is made available to, or how it is implemented, just that it
exists where appropriate.

         --Tom

>Service company that wants to stay in business, has it regardless

Success is relative; the more success, the more relatives. -Anonymous

---

From: Shahram Davari <[email-masked]>
Date: Mon, 7 Oct 2002 13:18:22 -0700

What if one wants to manually check the switching tables of all P LSRs
to find a defect? Why should PWE3 care about that?

If you want to add the transport-LSP traceroute, then please add meal, housing,
healthcare, coffee, etc. for the staff that will be using it as PWE3 requirements too !

-Shahram

> Sent: Monday, October 07, 2002 4:12 PM
> To: Shahram Davari
> Cc: [email-masked]

---

From: [email-masked]
Date: Mon, 7 Oct 2002 22:47:00 +0100

Shahram is absolutely right wrt his observations.  He is saying the same as
I am, albeit framed in a different way.  So I'll say it again as follows:
We want independent fault/perf handling of layer networks period.  Anything
less than this is unacceptable (for a whole raft of reasons).

I actually thought Tom was agreeing to this in his last response to me
however.

regards, Neil

> Sent: 07 October 2002 21:18
> To: 'Thomas D. Nadeau'
> Cc: [email-masked]

---

From: Danny McPherson <[email-masked]>
Date: Thu, 03 Oct 2002 10:28:25 -0600

> it can be done on a stand-alone basis as well.

Sure, though either way, we'll be looking for your feedback
on which terms are inaccurate.

Thanks!

-danny

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 04 Oct 2002 14:02:31 -0400

At 10:45 AM 10/4/2002 -0700, Shahram Davari wrote:
>but what Neil pointed out was that L2VPN and PWE3 are not using LDP-based 
>LSPs as the transport LSPs anyway, rather they use ER-LSPs.

         Huh? Which implementations of PWE/L3VPN have you been using?

         --Tom

>So the problem that you are faced

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Oct 2002 10:16:56 +0200

> E1 and T1 belong to PDH and only PDH.

Sorry Neil, but PLESIOchronous refers ONLY
to multiplexing of sources with NEARLY (BUT NOT EXACTLY)
the same clock (PLESIO is Greek for near or close).
(See G.701)

PDH thus refers to the hierarchy of multiplexing schemes 
that use with stuffing bits, e.g. E2,T2,E3,T3.

E1 and T1 mandate a single clock for all the DS0s they multiplex. 
They are thus not PLESIOchronous by any stretch of the imagination. 
They are simply synchronous (SYN means SAME).

Please do not fall into the same pit as someone did in
a previous thread on this list, and claim that various ITU
standards refer to E1 and T1 as PDH.  They don't.
They use the term BASED ON the 1544 kbps or 2048 kbps hierarchy.
The PDH hierarchy is BASED ON the E1 or T1 clocks,
but the E1/T1 signals themselves are NOT PDH.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Oct 2002 11:15:10 +0200

Yaakov and all,
Following your logic, VC4 does not belong to SDH because "S" in SDH
stands for SYNchronous, while VC4 clocks within an STM-n stream 
are controlled separately via - each via its own pointer adjustments.

IMHO, Neil's remark correctly reflects the common understanding
of the Telecom world to which the notion belongs.

With best regards,
                                   Sasha Vainshtein

> Sent: Tuesday, October 08, 2002 10:17 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 8 Oct 2002 11:36:19 +0200

Yaakov,

There is a different between the classification of TDM circuits into
plesiochronous digital hierarchy (PDH) and synchronous digital hierarchy
and the actual synchronization architecture deployed in the network, or
their internal multiplexing characteristics.

E1 and T1 are referred in the ITU specs as belonging to the
plesiochronous digital hierarchy (PDH). It does not matter that in most
deployments they are not operated in a plesiochronous timing
architecture, or that they carry DS0 synchronously.

To understand the difference, you might note that plesiochronous
synchronization is used in certain SDH deployments. This mode of
operation is typical for connections across administration boundaries.
SDH networks do not carry their PDH tributaries synchronously, but
rather asynchronous mapping are the dominant ones.

See an additional remarks below

Ron

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yaakov Stein

Below is G.701 definition. Please see Note 1.

6019	plesiochronous
	F:  plésiochrone
	S:  plesiócrono
The essential characteristic of time-scales or signals such that their
corresponding significant instants occur at nominally the same rate, any
variation in rate being constrained within specified limits.
NOTES
1	Two signals having the same nominal digit rate, but not stemming
from the same clock or homochronous clocks, are usually plesiochronous.
2	There is no limit to the time relationship between corresponding
significant instants.

> standards refer to E1 and T1 as PDH.  They don't. They use 
> the term BASED ON the 1544 kbps or 2048 kbps hierarchy. The 
> PDH hierarchy is BASED ON the E1 or T1 clocks, but the E1/T1 
> signals themselves are NOT PDH.
> 
> Y(J)S

---

From: [email-masked]
Date: Tue, 8 Oct 2002 11:03:07 +0100

Thanks...yes I know all this (I had a large hand in the E1 framing design
way back).  However, E1 and T1 are the foundation rates for the PDH....they
are not the foundation rates for the SDH or the OTN, that's all I
meant.....nothing more.

regards, Neil

> Sent: 08 October 2002 09:17
> To: neil.2.harrison; stbryant
> Cc: pwe3

---

From: [email-masked]
Date: Tue, 8 Oct 2002 11:03:09 +0100

Please see below.  regards, Neil

> From: Ron Cohen [mailto:[email-masked]]
> Sent: 08 October 2002 10:36
> To: 'Yaakov Stein'; neil.2.harrison; stbryant
> Cc: pwe3
NH=> It jolly well does Ron!  E1/T1 *must* be synchronous to the nx64k
clients they carry as there is no justification scheme that relates these 2
layer networks.  And in a PDH stack uncontrolled bit slips get removed at
the E1/T1 framing level.

---

From: "Ron Cohen" <[email-masked]>
Date: Tue, 8 Oct 2002 12:14:23 +0200

Neil,

> NH=> It jolly well does Ron!  E1/T1 *must* be synchronous to 
> the nx64k clients they carry as there is no justification 
> scheme that relates these 2 layer networks.  And in a PDH 
> stack uncontrolled bit slips get removed at the E1/T1 framing level. 

Yes. 
My point is that the fact that DS0s are carried synchronously within T1
and E1 does not change the fact that T1 and E1s belong to the
plesiochronous digital hierarchy (PDH)

Ron

> From: [email-masked] [mailto:[email-masked]] 
> Sent: Tuesday, October 08, 2002 12:03 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> > plesiochronous digital hierarchy (PDH) and synchronous digital 
> > hierarchy and the actual synchronization architecture 
> deployed in the
> > network, or
> > plesiochronous digital hierarchy (PDH). It does not matter that in 
> > most deployments they are not operated in a plesiochronous timing
> NH=> It jolly well does Ron!  E1/T1 *must* be synchronous to 
> the nx64k clients they carry as there is no justification 
> scheme that relates these 2 layer networks.  And in a PDH 
> stack uncontrolled bit slips get removed at the E1/T1 framing level. 
> > 
> > > to multiplexing of sources with NEARLY (BUT NOT EXACTLY) the same 
> > > clock (PLESIO is Greek for near or close). (See G.701)
> > 
> > corresponding significant instants occur at nominally the 
> same rate, 
> > any variation in rate being constrained within specified limits.
> > NOTES

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 8 Oct 2002 11:20:45 +0100

OK - so how about "synchronous bit-stream as defined in ITU spec blah blah
blah etc". That nails down the definitions to the selected types of streams
that PWE3 should (must?) address. Shouldn't the requirements document be
unambiguous and bounded w.r.t. this point at this juncture?

Bob

-snip-

---

From: "tom k. johnson" <[email-masked]>
Date: Tue, 8 Oct 2002 08:02:15 -0400

Bob/Yaakov -

I like that nomenclature as well.  

-Tom

> From: Bob Barrett [mailto:[email-masked]]
> Sent: Tuesday, October 08, 2002 6:21 AM
> To: Yaakov Stein; [email-masked]
> Cc: [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Oct 2002 14:29:01 +0200

> plesiochronous digital hierarchy (PDH). 

NO, they aren't.

> It does not matter 
> that in most deployments they are not operated in a plesiochronous timing

It is not that E1/T1 are not USUALLY used when DSOs are
not precisely synchronous, it is that they can NOT mux
such DS0s! They have no mechanism to match clocks!

> rather asynchronous mapping are the dominant ones.

Yes, SDH was built to float PDH tributaries,
but E1/T1 was not built to float or bit-stuff non-sync'ed DS0s.

> same rate, any

Thanks for the precise quote - it demonstrates precisely what I meant.

I know that some of you might be thinking that I am nit-picking
(as I was regarding the unframed vs unchannelized issue)
but standards documents have to be precise.

I am sure that if G.703 said that T1 has 
"about 24 octets per frame"
you would not be happy.
 
Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Oct 2002 14:32:16 +0200

> My point is that the fact that DS0s are carried synchronously 
> within T1and E1 does not change the fact that T1 and E1s belong to the

E1 and T1 existed BEFORE the PDH was ever defined.
(BTW the transistor was invented by Bell Labs NOT so that Sony
could make small radios, but to make T1 repeaters).

The PDH hierarchy was defined BASED ON their rates.

E1 and T1 do not need the PDH. The PDH does, however, need them.

Y(J)S

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Oct 2002 14:35:44 +0200

> I like that nomenclature as well.  

Which nomenclature the "blah blah etc." ?   :-)

I still think we should go with "TDM"
and defining that (in the definitions document?)
to mean synchronous bit streams
at rates defined by G.702.

Otherwise we will need to say E1/T1/PDH/SDH,
and then give the normative references to all of them.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Oct 2002 15:23:11 +0200

Yaakov,
What you are trying to say is that the basic elements of a 
certain hierarchy do not belong to it.
Sounds strange to me.

With best regards,
                                   Sasha Vainshtein

> Sent: Tuesday, October 08, 2002 2:29 PM
> To: Ron Cohen; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Yaakov Stein" <[email-masked]>
Date: Tue, 8 Oct 2002 16:42:59 +0200

Sasha, 

> certain hierarchy do not belong to it.

As Ron pointed out SONET/SDH multiplexes PDH signals
(e.g. OC-1 was devised to transport a DS3).

So do you propose calling a DS3 - SDH?
That would sound stranger!

The input doesn't matter. It is the technology used to multiplex that matters.

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Oct 2002 17:45:18 +0200

Yaakov and all,
Please see comments inline.

With best regards,
                                   Sasha Vainshtein

> Sent: Tuesday, October 08, 2002 4:43 PM
> To: Alexander Vainshtein
> Cc: [email-masked]; Ron Cohen; [email-masked]; 
> [email-masked]
I will use the SDH terms for clarity even when referring to "SONET/SDH".

Contrary to what Ron pointed out, SONET/SDH does _not_ directly
multiplex E1, DS1 or DS3. Strictly speaking (and I assume that
this is _your_ position) it _multiplexes_ administrative units (AU) and
tributary units (TU) .
AUs are multiplexed in a _synchronous way_ (i.e. are always
positioned at the same place relative to the SDH frame boundary);
TUs are multiplexed in a _synchronous_  way too, but relative to the
boundary of a high order VC. High order VCs are _floating_ within
their respective AUs, while low-order VCs are _floating_ within their
respective TUs.
This _multiplexing_ scheme does _not_ depend on payload of virtual
containers:
they may carry PDH signals, ATM packets or POS frames - just to name
a few options. And some containers may be left unequipped. 
> That would sound stranger!
As I have just said, DS3 (or, for that matter, DS1 or E1) signals are 
_not_ multiplexed per se in SONET/SDH. They are just _mapped_ into 
appropriate virtual containers: DS3 and E3 are mapped into VC3, E1 
is mapped into VC12 and DS1 is mapped into VC-11. 
POS frames and ATM cells can be mapped into any 
In other words, these signals are no more part of the SDH(ierarchy) 
that ATM cells or POS packets. On the other hand, AUs, TUs and VCs 
are part of this hierarchy. 

The details (including reference to multiplexing, aligning and mapping) 
can be found in G.707, Fig. 6.1 "Multiplexing Structure".

> The input doesn't matter. It is the technology used to 
Correct. That is why DS3 (which _directly_ multiplexes DS1 and E1), DS1 and
E1 belong
to a hierarhy that is commonly referred to as PDH. And that is why VC4, VC12
etc.
belong to a hierarchy that is commonly referred to as SDH.

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 8 Oct 2002 17:14:01 +0100

It's not uncommon to use PDH to map E1/T1 to T3 (e.g. G.747), then carry
3xT3 in an OC-3 or STM-1. T1 and E1 reprsent the majority of subscriber
needs for voice. T3 etc is either carrying multiple T1/E1 or data, and if
it's data I guess we are all assuming that the data services will migrate to
native Ethernet (eventually, about ten year before VoIP replaces E1 / T1 for
voice).

The inference being that the bulk of the application for PWE3 at the edge is
E1/T1 carrying voice over PSN, so may be we should focus on that. Carrier to
carrier probably starts with OC-3 / STM-1 rates.

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Ron
Cohen
Sent: 08 October 2002 10:36
To: 'Yaakov Stein'; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] comments on draft-ietf-pwe3-requirements-03.txt

Yaakov,

Ron

6019	plesiochronous
	F:  plsiochrone
	S:  plesicrono

---

From: "Bob Barrett" <[email-masked]>
Date: Tue, 8 Oct 2002 17:14:00 +0100

"blah blah etc." has been suitable translated by Yaakov to:

"synchronous bit streams at rates defined by G.702"

I was juts too lazy to do that myself ;-)

I agree with Yaakov i.e. use the _qualified_ definition of TDM, where TDM
means synchronous bit streams at rates defined by G.702.

Best regards

Bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Yaakov Stein
Sent: 08 October 2002 13:36
To: tom k. johnson; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [PWE3] comments on draft-ietf-pwe3-requirements-03.txt

Y(J)S

---

From: Sasha Vainshtein <[email-masked]>
Date: Tue, 8 Oct 2002 18:38:33 +0200

Bob, Yaakov and all,

"Rates defined by G.702" include (in addition to well-known
DS3, and somevhat less-known DS2,  E3 and E4):
1) in the hierarchy based on 1544 kbit/s (i.e., DS1):
   a) 32064 kbit/s
   b) 97728 kbit/s
2) in the hierararchy based on 2048 kbit/s (i.e., E1):
    a) 8448 kbit/s.

Does anybody _use_ these rates natively? And, if no one does
(as I strongly suspect), should we include them into the PWE3 
effort just for the sake of being able to specify TDM in a "nice" way?
E.g., could the results of such an effort be ever _verified_ 
(e.g., test several implementations for interoperability etc.)?

With best regards,
                                   Sasha Vainshtein

> Sent: Tuesday, October 08, 2002 6:14 PM
> To: Yaakov Stein; tom k. johnson; [email-masked]
> Cc: [email-masked]

---

From: [email-masked]
Date: Tue, 8 Oct 2002 19:23:20 +0100

Sasha...we have deprecated 8M and 34M for a long time.  History of PDH rates
(the 'x4' bit from E1 up) is related to electonics maturity at the
time.....nothing magical about them and they are not strong service rates
(for managed BW).

regards, Neil

> From: Sasha Vainshtein [mailto:[email-masked]]
> Sent: 08 October 2002 17:39
> To: [email-masked]'; Yaakov Stein
> Cc: [email-masked]; tom k. johnson; [email-masked]

---

From: "Bob Barrett" <[email-masked]>
Date: Wed, 9 Oct 2002 02:07:07 +0100

If it keeps the definition bounded then include these deprecated rates in
the requirements document definition.

Just because they are part of the definition does not make them mandatory in
an implementation, it just means that if a vendor chooses to implement one
of them, then that implementation can claim to comply with PWE3 (even though
sales may equal zero).

However, if there is a condition to have implementations in order to reach
rfc status then I guess we can't make the definition that simple and
concise. If that is the case can we not nail it down to T1 and E1, because
these are the likley 'saleable' rates?

Bob

- snip -

regards, Neil