Subject: RE: [PWE3] Charter Update: Last Call

From: Sasha Vainshtein <[email-masked]>
Date: Thu, 10 Nov 2005 23:09:44 +0200

Luca,
Assuming that a PW of type "IP" only passes IP packets
between its ACs, how would it work between, say,
a pair of Ethernet-based IP ACs? 

More specifically, which entity would respond to
ARP requests issued by a CE? This should
be the local PE (because ARP requests are not IP
packets and hence would not be passed across the "IP"
PW)... and in order to that it has to be aware of
the IP address and MAC address of the remote CE...

I'd like to repeat the last statement from my
original message to the list:

If the original intent is to specify encasulation of IP
packets over MPLS PWs and assign a PW Type to this construct,
let's state this explicitly.

Regards,
                      Sasha

> -----Original Message-----
> From: Luca Martini [mailto:[email-masked]]
> Sent: Thursday, November 10, 2005 9:00 PM
> To: Sasha Vainshtein
> Cc: 'Danny McPherson'; Stewart Bryant (E-mail); pwe3
> Subject: Re: [PWE3] Charter Update: Last Call
> 
> 
> Sasha,
> 
> This item is to allow a PW of type "IP".
> it also makes sure that we do not get into interworking if AC 
> technologies.
> 
> 
> Sasha Vainshtein wrote:
> > Danny, Stewart and all,
> > 
> > I have probably missed something, but I do not understand
> > the value of of the following work item:
> > 
> > <quote>
> > 	PWE3 will specify a PW type for the special case where the
> > 	access service payloads at both ends are known to consist
> > 	entirely of IP packets.  PWE3 will not specify mechanisms
> > 	by which a PW connects two different access services.
> > <end quote> 
> > 
> > E.g., suppose that you have two FR access (attachment?) services
> > that connect the PEs to CE routers.
> > 
> > How are we going to treat FR Inverse ARP packets the CEs send
> > to each other? If these are NOT consideredpart of the service
> > payload (because they are not IP), then Inverse ARP sill not
> > work and the CEs will, bost probably, simply refuse to exchange
> > IP packets.
> > 
> > And, in the case of Ethernet attachment circuits, what should
> > happen to ARP frames?
> > 
> No IP , hence they should be handled in the adaptation layer.
> 
> > The case of PPP attachment circuits is even more problematic 
> > since the IPCP state machine will probably never reach its "Open"
> > state.
> > 
> Again this is an adaptation layer function, not a PW  end to end one.
> 
> > IMO, there are just 3 options:
> > 
> > - Define explicit limitations on applicability of IP-only PWs (like,
> >   static ARP in the case of Ethernet attachment circuits etc.).
> >   This would work (with some exceptions, but the usefulness is 
> >   greatly reduced
> > 
> > - Support full-blown ARP mediation mechanisms as per 
> >   draft-ietf-l2vpn-arp-mediation-04.txt even for IP PWs with
> >   the same L2 attachment circuits. This would be OK (still with some
> >   known applicability restrictions) but, if we do that, why 
> should we
> >   care about same or different attachment circuits?
> > 
> > - Carry the Layer 2 circuit (in which case there is no need
> >   for IP-only PWs).
> > 
> > 
> > If the intention has been to define encapsulation of IP
> > packets over PW that could be used in the ARP mediation
> > draft, let's state this explicitly.
> This is just a charter, I do not think it has to have a llthe 
> solution 
> details ...
> 
> Luca
> 
> > 
> > Regards,
> >                         Sasha
> >> -----Original Message-----
> >> From: Danny McPherson [mailto:[email-masked]]
> >> Sent: Monday, November 07, 2005 6:00 PM
> >> To: pwe3
> >> Subject: [PWE3] Charter Update: Last Call
> >>
> >>
> >> 	
> >>
> >> Folks,
> >> Here's a final cut of the charter incorporating all feedback
> >> received to date.  The most recent change is the addition of
> >> PW protection and restoration.
> >>
> >> If no significant comments are received I'd like to pass this
> >> along to the IESG on 11/14.
> >>
> >> Thanks!
> >>
> >> -danny & Stewart
> >>
> >> -------
> >> Pseudo Wire Emulation Edge to Edge (PWE3) WG
> >>
> >> Description of Working Group:
> >>
> >> Network transport service providers and their users are
> >> seeking to rationalize their networks by migrating their
> >> existing services and platforms onto IP or MPLS enabled
> >> IP packet switched networks (PSN).  This migration requires
> >> communications services that can emulate the essential
> >> properties of traditional communications links over a PSN.
> >>
> >> Pseudowire Emulation Edge to Edge (PWE3) will specify the
> >> encapsulation, transport, control, management, interworking and
> >> security of services emulated over IETF specified PSNs.
> >>
> >> A pseudowire emulates a point-to-point link, and provides a
> >> single service which is perceived by its user as an unshared
> >> link or circuit of the chosen service.  It is not intended that
> >> an emulated service will be indistinguishable from the service
> >> that is being emulated.  The emulation need only be sufficient
> >> for the satisfactory operation of the service.  Emulation
> >> necessarily involves a degree of cost-performance trade-off.
> >> In some cases it may be necessary to design more than one
> >> emulation mechanism in order to resolve these design
> >> conflicts.  All emulated service definitions must include an
> >> applicability statement describing the faithfulness of the
> >> emulation.  Switching, multiplexing, modification or other
> >> operation on the traditional service, unless required as
> >> part of the emulation, is out of the scope of the PWE3 WG.
> >>
> >> PWE3 will make use of existing IETF specified mechanisms
> >> unless there are technical reasons why the existing mechanisms
> >> are insufficient or unnecessary.
> >>
> >> PWE3 operates "edge to edge" and will not exert control on
> >> the underlying PSN, other than to use any existing QoS or
> >> path control mechanism to provide the required connectivity
> >> between the two endpoints of the PW.
> >>
> >> PWE3 will investigate mechanisms necessary to perform clock
> >> recovery and other real-time signaling functions.  This work will
> >> be coordinated with the AVT WG and RTP will be used where
> >> appropriate.
> >>
> >> A PW operating over a shared PSN does not necessarily have
> >> the same intrinsic security as a dedicated, purpose built,
> >> network.  In some cases this is satisfactory, while in other
> >> cases it will be necessary to enhance the security of the PW
> >> to emulate the intrinsic security of the emulated service.
> >> PW specifications MUST include a description of how they
> >> are to be operated over a shared PSN with adequate security.
> >>
> >> Whilst a service provider may traffic engineer their network
> >> in such a way that PW traffic will not cause significant
> >> congestion, a PW deployed by an end-user may cause
> >> congestion of the underlying PSN.  Suitable congestion
> >> avoidance mechanisms are therefore needed to protect the
> >> Internet from the unconstrained deployment of PWs.
> >>
> >> PWE3 will work closely with the L2VPN WG to ensure a clear
> >> demarcation is defined for where PWE3 stops and L2VPN starts.
> >> PWE3 will coordinate very closely with any WG that is
> >> responsible for protocols which PWE3 intends to extend (e.g.,
> >> the MPLS WG for LDP), as well as foster interaction with WGs
> >> that intend to extend PWE3 protocols.
> >>
> >> WG Objectives:
> >>
> >> Specify the following PW types:
> >>
> >> Ethernet, Frame Relay, PPP, HDLC, ATM, low-rate TDM,
> >> SONET/SDH and Fibre Channel.
> >>
> >> PWE3 will specify a PW type for the special case where the
> >> access service payloads at both ends are known to consist
> >> entirely of IP packets.  PWE3 will not specify mechanisms
> >> by which a PW connects two different access services.
> >>
> >> Specify the control and management functions of chartered PW
> >> types, to include PW setup, configuration, maintenance and
> >> tear-down.  The PWE3 WG will do this in its entirety for
> >> MPLS PSNs, and the L2TPEXT WG will develop the L2TP specifics
> >> for L2TPv3-based PWs.
> >>
> >> Specify Operations and Management (OAM) mechanisms for all
> >> PW types, suitable for operation over both IP/L2TPv3 and
> >> MPLS PSNs, and capable of providing the necessary
> >> interworking with the OAM mechanisms of the emulated
> >> service.
> >>
> >> Further enhance PW specifications to enable more transparent
> >> emulation when necessary, for example the retention of FCS
> >> across a PW.
> >>
> >> Define a mechanism for MPLS PWs that provides interoperability
> >> with currently deployed equal cost multiple path (ECMP)
> >> algorithms such that packets for a given PW follow the same
> >> path through an MPLS PSN.
> >>
> >> Define requirements for and mechanisms to provide
> >> interconnection of PWs (to include inter-domain PWs).
> >>
> >> Define requirements for and mechanisms to provide
> >> protection and restoration of PWs.
> >>
> >>
> >> _______________________________________________
> >> pwe3 mailing list
> >> [email-masked]
> >> https://www1.ietf.org/mailman/listinfo/pwe3
> >>
> > 
> > _______________________________________________
> > pwe3 mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/pwe3
> 

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

---

From: Danny McPherson <[email-masked]>
Date: Fri, 11 Nov 2005 08:56:36 -0700

> let's state this explicitly.

Unless some profound new objection occurs I'd prefer to leave
it as is, as I believe the current wording is sufficient.  It's been  
there
for the last few revisions based on some earlier recommendations
from folks and seems to capture the objective well enough.

Thanks!

-danny

---

From: Stewart Bryant <[email-masked]>
Date: Mon, 14 Nov 2005 11:31:51 +0000

I Share Sasha's concern that we may need to pass more
than IP over the PW. However I think that we should
solve the detail in the WG, not the charter.

- Stewart