Subject: Comments to draft-ietf-pwe3-arch-00

From: Sasha Vainshtein <[email-masked]>
Date: Fri, 18 Oct 2002 12:22:26 +0200

Stewart, Prayson and all,
Congratulations for a very high-quality document!

I am sending some comments inserted in the related
context of the document and marked [Sasha] for your convenience.
Most are editorial or suggestions for clarifications.
Hopefully you will find some of them useful.

In addition there is one generic issue I would like to raise:
multicast functionality in PWE3,i.e. P2MP PWs.

I am not a multicast expert, and I can be absolutely wrong, but
I have a feeling that P2MP PWs have not been designed
in depth - definitely not at the same level of technical excellency
as the rest of the issues discussed in the draft. Please note that:
1. No reference models for P2MP PWs have been explicitly presented
2. The desired behavior of the PW Demultiplexing in case of P2MP
   PWs is not defined: e.g., should all the egress PEs of a P2MP PW 
   agree on a common value of the PW Demultiplexer that identifies this PW
   and,if so, how can this functionality be achieved in a consistent way
   (consider the case when one more PE joins the multicast destination
   group). If not (i.e., if each egress PE requires its own PW 
   Demultiplexer value), does - or does not - it mean that multicasting 
   is done by the FWRD and hence is out of scope of PWE3?
3. None of the protocol instanciation schemes explicitly addresses
   P2MP issues. Indeed, the proposed instanciation over an IP PSN
   (L2TPv3-based) presumably cannot handle P2MP issues (L2TPv3 is
   P2P, isn't it?), and P2MP issues in MPLS networks are, AFAIK, at
   quite an early stage of development.

If you add to that, AFAIK, none of the specific protocols designed
in the PWE3 WG address P2MP issues and that the interest in these
issues (judging by what passes on the list) seems to be negligible,
I suggest to consider the following options:
1. Define P2MP issues as being out of scope of the PWE3 activities.
   (This would result in a modification of the WG Charter).
2. Limit the architecture (and requirements) documents to just 
   mentioning that P2MP PWs "are left for further study" and wait 
   to see if any real interest develops.

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

===================Text fragments with inserted comments BEGIN========

Pseudo-Wire Edge-to-Edge (PWE3) Working Group             Stewart Bryant
Internet Draft                                             Cisco Systems
Document: <draft-ietf-pwe3-arch-00.txt>
Expires: April 2003                                         Prayson Pate
                                                 Overture Networks, Inc.

                                                                 Editors

                                                            October 2002

                           PWE3 Architecture

... skipped ...
   1.4 Terminology

... skipped ...

   Maximum transmission The packet size (excluding data link header)
   unit (MTU)           that an interface can be transmit without
                        needing to fragment.  ^
                                              |
[Sasha] -------------Isn't it suprefluous?-----

   Native Service       Processing of the data received by the PE
   Processing (NSP)     from the CE before presentation to the PW
                        for transmission across the core.

... skip ...

3.3.2.  Cell Payload

   A cell payload is created by capturing, transporting and replaying
   groups of bits presented on the wire in a fixed-size format.  The
   delineation of the group of bits that comprise the cell is specific
   to the encapsulation type.  Two common examples of cell payloads are
   53-octet cells carrying ATM AAL2, and the larger 188-octet MPEG
   Transport Stream packets [ETSI].

[Sasha] There is nothing specific about AAL2 in this example. AAL1
[Sasha] would do as well. What's more, the ATM-related drafts discussed
[Sasha] in the WG consider "VP mode" PWs when more than one ATM 
[Sasha] Adaptation Layer (AAL) can be carried on the same PW. 
[Sasha] Would you consider "ATM 53-octet cells" instead?

Bryant and Pate.             Informational                     [Page 11]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

   To reduce per-PSN packet overhead, multiple cells may be concatenated
   into a single payload.  The Encapsulation Layer may consider the
   payload complete on the expiry of a timer, or after a fixed number of
   cells have been received.  The benefit of concatenating multiple PDUs
[Sasha] Yet another possibility that has been discussed on the list
[Sasha] is to consider the payload complete if a "special" cell
[Sasha] (e.g., an ATM OAM cell) has been received at ingress.
   should be weighed against the resulting increase in jitter and the
   larger penalty incurred by packet loss.  In some cases, it may be
   appropriate for the Encapsulation Layer to perform a silence
   suppression or a similar compression.

   The generic cell payload service will normally need sequence number
   support, and may also need real-time support.  The generic cell
   payload service would not normally require fragmentation.
[Sasha] It may be worth noting that cell payload usually
[Sasha] do not requires length services from either the 
[Sasha] PSN or the PSN Convergence sub-layer. 
   The Encapsulation Layer may apply some form of compression to some of
   these sub-types.
[Sasha] Sorry, but I do not understand the statement above. IMHO some
[Sasha] clarification would be in place (e.g., "idle cells may be 
[Sasha] suppressed?")
   In some instances, the cells to be incorporated in the payload may be
   selected by filtering them from the stream of cells presented on the
   wire.  For example, an ATM PWE3 service may select cells based on
   their VCI or VPI fields. This is an NSP function, and the selection
[Sasha] Is it not a FWRD function just like in case of a DLCI-based
[Sasha] selection for FR in 3.3.1? I do not see any difference here
   would therefore be made before the packet was presented to the PW
   Encapsulation Layer.

3.3.3.  Bit-stream

   A bit-stream payload is created by capturing, transporting and
   replaying the bit pattern on the emulated wire, without taking
   advantage of any structure that, on inspection, may be visible within
   the relayed traffic (i.e. the internal structure has no effect on the
   fragmentation into packets).  The Encapsulation Layer submits an
   identical number of bits for transport in each PW-PDU.

   This service will require sequencing and real-time support.

3.3.4.  Structured bit-stream

   A bit-stream payload is created by using some knowledge of the
   underlying structure of the bit-stream to capture, transport and
   replay the bit pattern on the emulated wire (i.e. the internal
   structure directly effects the fragmentation into packets).
[Sasha] I am not sure that text in parentheses correctly describes
[Sasha] the technique for carrying structured SONET/SDH over PWs 
[Sasha] presented in draft-ietf-pwe3-sonet-00.txt. I suggest to 
[Sasha] omit it.

   Two important points distinguish structured and unstructured bit-
   streams:

       o Some part of the original (unstructured) bit-stream are
         stripped by, for example, the PSN-bound direction of the
         NSP block.  For example, in Structured SONET the section
         and line overhead (and, possibly, more) may be stripped.

[Sasha] IMHO the first occurrence of "for example" in the text above
[Sasha] is superfluous. I also think that structured bit-stream services
[Sasha] can only exist in conjunction with an appropriate NSP block 
[Sasha] (commonly called "framer") in the PE providing such a service. 
[Sasha] If such an approach is acceptable, it would be worth adding 
[Sasha] appropriate text. The alternative possibility - that the 
[Sasha] structure is imposed on a "native" bit-stream by the PW 
[Sasha] IWF - does not look consistent with the rest of the document.

Bryant and Pate.             Informational                     [Page 12]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

       o The PW must preserve the structure across the PSN so that
         the CE-bound NSP block can insert it correctly into the
         reconstructed unstructured bit-stream.

   The Encapsulation Layer may also perform silence/idle suppression or
   similar compression on a structured bit-stream.
[Sasha] Some forms of suppression can be applied to bit-streams as well.
[Sasha] E.g., E1 and T1 send "all-ones" to indicate a fauilure. Such a 
[Sasha] condition can be detected regardless of any structure imposed
[Sasha] on the stream, and actual transmission of packetized data
[Sasha] can be suppressed as a consequent action.
   Structured bit-streams are distinguished from cells in that the
   structures may be too long to be carried in a single packet (i.e.
   structured SONET).  Note that "short" structures are
   indistinguishable from cells and may benefit from the use of cell
   encapsulations.
[Sasha] I assume that the meaning here is "may benefit from the
[Sasha] use of encapsulations used for cell payload" as opposed
[Sasha] to "use of double encapsulations: payload-->cell-->packet".
[Sasha] IMHO a clarification would be in place. 

   This service will require sequencing and real-time support.

3.3.5.  Principle of Minimum Intervention

   To minimise the scope of information, and to improve the efficiency
   of data flow through the Encapsulation Layer, the payload should be
   transported as received with as few modifications as possible
   [RFC1958].

   This minimum intervention approach decouples payload development from
   PW development and requires fewer translations at the NSP in a system
   with similar CE interfaces at each end.  It also prevents any
   unwanted side-effects due to subtle mis-representation of the payload
   in the intermediate format.
[Sasha] The Principle of Minimum Intervention (PMI) definitely reduces 
[Sasha] the "window of opportunity" for mis-interpretations. However, 
[Sasha] I suspect that "any" in the last sentence is a bit too strong.

   An intervention approach can be more wire-efficient in some cases and
   may result in fewer translations at the NSP where the CE interfaces
   are of different types. Any intermediate format effectively becomes a
   new framing type, requiring documentation and assured
   interoperability.  This increases the amount of work for handling the
   protocol the intermediate format carries, and is undesirable.

... skip ...

5.1  Payload Convergence Layer

5.1.1.  Encapsulation

   The primary task of the Payload Convergence Layer is the
   encapsulation of the payload in PW-PDUs.  The native data units to be
   encapsulated may or may not contain L2 or L1 header information.
[Sasha] I am not sure that the term "L1 header" is really appropriate.
[Sasha] Would you consider "L1 overhead" instead?
   This is service specific.  The Payload Convergence header carries the
   additional information needed to replay the native data units at the
   CE-bound physical interface. The PW Demultiplexer header is not
   considered as part of the PW header.

Bryant and Pate.             Informational                     [Page 22]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

   Not all the additional information needed to replay the native data
   units need to be carried in the PW header of the PW PDUs.  Some
   information (e.g. service type of a PW) may be stored as state
   information at the destination PE during PW set-up.

5.1.2.  PWE3 Channel Types

   The PW Encapsulation Layer and its associated signaling require one
   or more of the following types of channels from its underlying PW
   Demultiplexer and PSN Layers:

   1. A reliable control channel for signaling line events, status
      indications, and, in some exceptional cases, CE-CE events
      that must be translated and sent reliably between PEs.

      For example, this capability is needed in [PPPoL2TP]
      (PPP negotiation has to be split between the two ends of the
      tunnel).  PWE3 may also need this type of control channel to
      provide faithful emulation of complex data-link protocols.

   plus one or more data channels with the following characteristics:

   2. A high-priority, unreliable, sequenced channel.  A typical use
      is for CE-to-CE signaling.  "High priority" may simply be
      indicated via DSCP/EXP bits for priority during transit.
      This channel type could also use a bit in the tunnel header
      itself to indicate that packets received at the PE should be
      processed with higher priority [RFC2474].

   3. A sequenced channel for data traffic that is sensitive to
      packet reordering (one classification for use could be for
      any non-IP traffic).

   4. An un-sequenced channel for data traffic insensitive to packet
      order.

   The data channels (2, 3 and 4 above) should be carried "in band" with
   one another to as much of a degree as is reasonably possible on a
   PSN.

   Where end-to-end connectivity may be disrupted by address translation
   [RFC3022], access-control lists, firewalls etc., there exists the
   possibility that the control channel may be able to pass traffic and
   set up the PW, but the PW data-path data traffic is blocked by one or
[Sasha] IMHO at least one occurrence of "data" in line above is superfluos.
   more of these mechanisms.  In these cases unless the control channel
   is also  carried "in  band" the  signaling to set-up the PW will not
   confirm the existence of an end-to-end data path.

Bryant and Pate.             Informational                     [Page 23]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

   In some cases there is a need to synchronize some CE events with the
   data carried over a PW.  This is especially the case with TDM
   circuits (e.g., on-hook/off-hook events in PSTN switches).
[Sasha] IMHO it would be worth mapping this example to one of
[Sasha] the channel classes deiscussed in this section.

   PWE3 channel types that are not needed by the supported PWs need not
   be included in such an implementation.

... skip ...

5.2.1.  Sequencing

   The sequencing function provides three services: frame ordering,
   frame duplication detection and frame loss detection. These services
   allow the invariant properties of a physical wire to be emulated.
[Sasha] Would you consider "allow emulation of invariant properties
[Sasha] of a physical wire" as a replacement?
   Support for sequencing depends on the payload type, and may be
   omitted if not needed.

   The size of the sequence-number space depends on the speed of the
   emulated service, and the maximum time of the transient conditions in
   the PSN.  A sequence number space greater than approximately 2^16 may

Bryant and Pate.             Informational                     [Page 24]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

   therefore be needed to prevent the sequence number space wrapping
   during the transient.

... skip ...

5.2.2.  Timing

   A number of native services have timing expectations based on the
   characteristics of the networks that they were designed to travel
   over, and it can be necessary for the emulated service to duplicate
   these network characteristics as closely as possible, e.g. in
   delivering native traffic with the same jitter, bit-rate and timing
   characteristics as it was sent.

   In such cases, it is necessary for the receiving PE to play out the
   native traffic as it was received at the sending PE.  This relies on
   either timing information sent between the two PEs, or in some case
   timing information received from an external reference.

   The Timing Sub-layer must therefore support two timing functions:
   clock recovery and timed payload delivery.  A particular payload type
   may require either or both of these services.

5.2.2.1  Clock Recovery

   Clock recovery is the extraction of output transmission bit timing
   information from the delivered packet stream, and requires a phase-
   locking mechanism.  A physical wire provides this naturally, but it
[Sasha] I am not sure that a physical wire naturally provides a phase-
[Sasha] locking mechanism or even ability to extract bit timing 
[Sasha] information. I agree that extraction of bit timing information
[Sasha] from bit streams running over physical wires is a well-known
[Sasha] techical problems with off-the-shelf available solutions.  
   is a relatively complex task to extract this from a highly jittered
   source such as packet stream.  It is therefore desirable that an
   existing real-time protocol such as [RFC1889] be used for this
   purpose, unless it can be shown that this is unsuitable or
   unnecessary for a particular payload type.

5.2.2.2  Timed delivery

   Timed delivery is the delivery of non-contiguous PW PDUs to the PW
   output interface with a constant phase relative to the input
   interface.  The timing of the delivery may be relative to a clock
   derived from the packet stream via clock recovery, or via an external
   clock.
[Sasha] Sorry, I do not understand the para above. 
... skip ...

5.4.1. PWE3 over an IP PSN

   The protocol definition of PWE3 over an IP PSN should employ existing
   IETF protocols where possible.

[Sasha] Are Fig. 10 and related explanatory text an example, a
[Sasha] recommendation or the mandatory instanciation? IMHO some
[Sasha] clarification would be in place (e.g., via judicious use of
[Sasha] capitalized "MAY", "SHOULD" and "MUST").

Bryant and Pate.             Informational                     [Page 27]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

       +---------------------+              +-------------------------+
       |      Payload        |------------->| Raw payload if possible |
       /=====================\              +-------------------------+
       H Payload Convergence H------------->|        As Needed        |
       H---------------------H              +-------------------------+
       H       Timing        H----------+-->|            RTP          |
       H---------------------H         /    +-------------+           |
       H     Sequencing      H----one of    |             |
       \=====================/         \    |             +-----------+
       |  PW Demultiplexer   |----------+-->|     L2TP, MPLS etc.     |
       +---------------------+              +-------------------------+
       |  PSN Convergence    |------------->|       Not needed        |
       +---------------------+              +-------------------------+
       |        PSN          |------------->|            IP           |
       +---------------------+              +-------------------------+
       |    MAC/Data-link    |------------->|       MAC/Data-link     |
       +---------------------+              +-------------------------+
       |       Physical      |------------->|          Physical       |
       +---------------------+              +-------------------------+

   Figure 10: PWE3 over an IP PSN

   Figure 10 shows the protocol layering for PWE3 over an IP PSN. As a
   rule, the payload should be carried as received from the NSP, with
   the Payload Convergence Layer provided when needed.  (It is accepted
   that there may sometimes be good reason not to follow this rule, but
   the exceptional circumstances need to be documented in the
   Encapsulation Layer definition for that payload type).

   Where appropriate, timing is provided by RTP [RFC1889], which when
   used also provides a sequencing service.  PW Demultiplexing may be
   provided by a number of existing IETF tunnel protocols.  Some of
   these tunnel protocols provide an optional sequencing service.
   (Sequencing is provided either by RTP, or by the PW Demultiplexer
   Layer, but not both).  A PSN Convergence Layer is not needed, because
   all the tunnel protocols shown above are designed to operate directly
   over an IP PSN.

   As a special case, if the PW Demultiplexer is an MPLS label, the
   protocol architecture of section 5.4.2 can be used instead of the
   protocol architecture of this section.

5.4.2. PWE3 over an MPLS PSN

   The MPLS ethos places importance on wire efficiency.  By using a
   control word, some components of the PWE3 protocol layers can be
   compressed to increase this efficiency.

Bryant and Pate.             Informational                     [Page 28]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

       +---------------------+
       |      Payload        |
       /=====================\
       H Payload Convergence H-----------------+
       H---------------------H                 |
       H       Timing        H                 |
       H---------------------H                 |
       H     Sequencing      H-----------------|
       \=====================/                 |
       |  PW Demultiplexer   |---+             |
       +---------------------+   |             |
       |  PSN Convergence    |-----------------|
       +---------------------+   |             |
       |        PSN          |-+ |             v
       +---------------------+ | |  +--------------------------------+
       |    MAC/Data-link    | | |  | Flags, Frag, Len, Seq #, etc   |
       +---------------------+ | |  +--------------------------------+
       |       Physical      | | +->|          Inner Label           |
       +---------------------+ |    +--------------------------------+
                               +--->| Outer Label or MPLS-in-IP encap|
                                    +--------------------------------+

   Figure 11: PWE3 over an MPLS PSN using a control word

   Figure 11 shows the protocol layering for PWE3 over an MPLS PSN.  An
   inner MPLS label is used to provide the PW demultiplexing function.
   A control word is used to carry most of the information needed by the
   PWE3 Encapsulation Layer and the PSN Convergence Layer in a compact
   format.  The flags in the control word provide the necessary payload
   convergence.  A sequence field provides support for both in-order
   payload delivery and (supported by a fragmentation control method) a
   PSN fragmentation service within the PSN Convergence Layer.  Ethernet
   pads all frames to a minimum size of 64 bytes. The MPLS header does
   not include a length indicator. Therefore to allow PWE3 to be carried
   in MPLS to correctly pass over an Ethernet data-link, a length
   correction field is needed in the control word.

   In some networks it may be necessary to carry PWE3 over MPLS over IP.
   In these circumstances, the PW is encapsulated for carriage over MPLS
   as described in this section, and then a standard method of carrying
   MPLS over an IP PSN (such as GRE [RFC2784], [RFC2890]) is applied to
   the resultant PW-PDU.

[Sasha] Fig. 11 assumes that timing services over an MPLS PSN are provided
[Sasha] by the control word alone preculding use of RTP. Is such a reduction
[Sasha] really justified?  It also seems to contradict Fig. 10 that allows
[Sasha] a combination of RTP and MPLS-based PW demultiplexing.

... skip ...

8. Management and Monitoring

   This section describes the management and monitoring architecture for
   PWE3.

8.1  Statistics

   The PE can tabulate statistics that help monitor the state of the
   network, and to help with measurement of service level agreements
   (SLAs). Typical counters include:

       o Counts of PW-PDUs sent and received, with and without errors.
       o Counts of sequenced PW-PDUs lost.
       o Counts of service PDUs sent and received, with and without
         errors (non-TDM).
[Sasha] It is not clear whether the bullet above refers to the service
[Sasha] send/received from the network or from the AC. If the former
[Sasha] is intended, then the reference to service PDUs received with
[Sasha] errors is not clear.  If the latter is intended, it is probably
[Sasha] by the bullet below.
       o Service-specific interface counts.

   These counters would be contained in a PW-specific MIB, and they
   should not replicate existing MIB counters.

... skip...

8.3 Connection Verification and Traceroute

   A connection verification mechanism should be supported by PWs.
   Connection verification as well as other alarming mechanisms can
   alert the operator that a PW has lost its remote connection.  The
   opaque nature of a PW means that it is not possible to specify a
   generic connection verification or traceroute mechanism that passes
   this status to the CEs over the PW.  If connection verification
   status of the PW is needed by the CE, it must be mapped to the native
   connection status method.

   For troubleshooting purposes, it is sometimes desirable to know the
   exact functional path of a PW between PEs, thus a traceroute function
   capable of reporting the path taken by data packets over the PW
   should be provided. The opaque nature of the PW means that this
   traceroute information is only available within the provider network
   e.g. at the PEs.
[Sasha] We have just had a long discusion on tunnel and PW tracing during
[Sasha] the WG Last Call on the PWE3 requirements document. I suggest to
[Sasha] wait and see which course of action is taken by the authors of
[Sasha] requirements document. In any case the para above sounds like
[Sasha]a requirement to me as it does not introduce any architecture.

9.  IANA considerations

   There are no IANA considerations for this document.

10.  Security Considerations

   PWE3 provides no means of protecting the contents or delivery of the
   native data units.  PWE3 may, however, leverage security mechanisms
   provided by the PW Demultiplexer or PSN Layers, such as IPSec
   [RFC2401].  This section addresses the PWE3 vulnerabilities, and the
   mechanisms available to protect the emulated native services.

   The PW Tunnel End-Point, PW Demultiplexing mechanism, and the
   payloads of the native service are all vulnerable to attack.

10.1  PW Tunnel End-Point and PW Demultiplexer Security

   Protection mechanisms must be considered for the PW Tunnel end-point
   and PW Demultiplexer mechanism in order to avoid denial-of-service
   attacks upon the native service, and to prevent spoofing of the
   native data units.  Exploitation of vulnerabilities from within the
   PSN may be directed to the PW Tunnel end-point so that PW
   Demultiplexer and PSN tunnel services are disrupted.  Controlling PSN
   access to the PW Tunnel end-point may protect against this.

Bryant and Pate.             Informational                     [Page 38]

INTERNET DRAFT        draft-ietf-pwe3-arch-00.txt             April 2002

   By restricting PW Tunnel end-point access to legitimate remote PE
   sources of traffic, the PE may reject traffic that would interfere
   with the PW Demultiplexing and PSN tunnel services.

10.2  Validation of PW Encapsulation

   Protection mechanisms must address the spoofing of tunneled PW data.
   The validation of traffic addressed to the PW Demultiplexer end-point
   is paramount in ensuring integrity of PW encapsulation.  Security
   protocols such as IPSec [RFC2401] may be used by the PW Demultiplexer
   Layer in order to maintain the integrity of the PW by authenticating
   data between the PW Demultiplexer End-points.  IPSec may provide
   authentication, integrity, non-repudiation, and confidentiality of
   data transferred between two PEs.  It cannot provide the equivalent
   services to the native service.
[Sasha] IMHO, the PMI implies that authentication,integrity etc. services
[Sasha] to the native service are NOT provided by any element in the PWE3
[Sasha] domain. The only place for these would be in the NSP.

... skipped to the end ...
===================Text fragments with inserted comments END=========

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 31 Oct 2002 18:46:34 +0000

The following is an extract from Sasha's feedback re the arch
document.

My assumption is that PWE3 are just defining the wires, and
that it is the NSP & Forwarding functions that convert
these wires into a multi-point system as and when needed.
Multi-point therefore falls into the scope of PPVPN and not
PWE3. This seems consistent with the charter. Do others agree?

The only flaw that I can see with this approach is that we
will not be taking advantage of IP multcast, but as Sasha
points out we have not given any serious thought to how
to set up multicast PWs. If we do need multipoint, do we
need to do it now, or can we punt to a later phase?

Stewart

---

From: Eric Rosen <[email-masked]>
Date: Thu, 31 Oct 2002 14:23:55 -0500

Stewart> My assumption is that PWE3 are just defining the wires, and that it
Stewart> is the NSP  & Forwarding functions that convert  these wires into a
Stewart> multi-point system as and  when needed. Multi-point therefore falls
Stewart> into the  scope of PPVPN and  not PWE3. This  seems consistent with
Stewart> the charter. Do others agree? 

Creating  a  multi-point system  out  of p2p  wires  is  definitely a  PPVPN
function  rather  than a  PWE3  function.  But  that  doesn't  rule out  the
possibility of PWE3 defining a p2mp wire of some sort.  Whether such a thing
is actually needed is an open question.

I think this should just be punted for now, left "for further study".

---

From: "Cheng-Yin Lee" <[email-masked]>
Date: 31 Oct 2002 15:02:00 -0500

All,
>From the PWE3 WG charter:

> Out of Scope
>
> Any multicast service not native to the emulated medium. Thus, Ethernet
> transmission to a "multicast" IEEE-48 address is in scope, while multicast
> services like MARS that are implemented on top of the medium are out of scope.

Recently, I discussed this with the PWE3 Chair and Technical Advisor and my
understanding is an emulation of an Ethernet wire should support Ethernet
multicast/broadcast and is also within the scope the PWE3 charter. (A PPVPN/VPL
may have additional requirements besides the emulation of an Ethernet wire).
What do others think?

thanks
cheng-yin

Eric Rosen wrote:

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