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

From: Stewart Bryant <[email-masked]>
Date: Wed, 02 Oct 2002 20:25:01 +0100

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?

    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

    and the resulted frames are forwarded in their native format to the
    other CE.

<snip>

    Customer Edge      A Customer Edge (CE) is a device where one end of
                       an emulated service originates and terminates. The
                       CE is not aware that it is using an emulated
                       service rather than a "real" service.

SB> native would be a better term than real

    Provider Edge      A Provider Edge (PE) is a device that provides
                       PWE3 to a CE.

    Pseudo Wire        A Pseudo Wire (PW) is a connection between two PEs
                       carried over a PSN. The PE provides the adaptation
                       between the CE and the PW.

SB>    Pseudo Wire (PW)     A mechanism that carries the essential
SB>                         elements of an emulated service from one PE
SB>                         to one or more other PEs over a PSN.

    Pseudo Wire PDU    A Pseudo Wire PDU (PW PDU) is a PDU sent on the PW
                       that contains all of the data and control
                       information necessary to provide the desired
                       service.

    PSN Tunnel         A PSN Tunnel is a tunnel inside which multiple PWs
                       can be nested so that they are transparent to core
                       network devices.

SB>   PSN Tunnel           A tunnel across a PSN inside which one or
SB>                        more PWs can be carried.

    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?

    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 definitions
SB> with it. Move it to the bottom where you define it out of scope.

    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?

    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?

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

    If a native service has keep-alive mechanism, the corresponding
    emulated service MUST define a similar mechanism for 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>

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.

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>

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

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

SB> as high -> the same?

    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.

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?

      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?

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?

<snip>

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.

SB> PW over IP cannot tell whether it's going over an AB or not.

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.

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.

SB> Do you mean MUST? The implication is that only IPsec can be used
SB> for the IP tunnel.

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: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 02 Oct 2002 15:39:52 -0400

One comment inline.

>SB> of the wire. This needs to be re-written or deleted.

         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.

         --Tom

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

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

---

From: [email-masked]
Date: Thu, 3 Oct 2002 09:08:41 +0100

Thomas D. Nadeau wrote 02 October 2002 20:40

<snipped>
> I would be okay to change "MUST" to "SHOULD" if that would
NH=> The operations requirements don't specifically ask for trace-route or
LSP-Ping.....that is your interpretation.  Operations people now want to
able to manage the technoloogy they have been sold that came without any
such fault-management tools.  The p2p case of LSPs is trivally solved with
Y.1711...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: Thu, 03 Oct 2002 09:56:19 -0400

At 09:08 AM 10/3/2002 +0100, [email-masked] wrote:
>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".

>Operations people now want to
>such fault-management tools.

         Lets not exaggerate. Most devices come with at least
some fault-management tools.

>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.

         --Tom

>and you cannot get any simpler than that as you ought to know.  LDP

---

From: Shahram Davari <[email-masked]>
Date: Thu, 3 Oct 2002 07:13:19 -0700

> specification will not work for  LSP-signaled LSPs in any 

What do you mean LSP-signaled LSPs?

-Shahram