Subject: PWE3 IETF53 - Final Minutes

From: Danny McPherson <[email-masked]>
Date: Thu, 04 Apr 2002 23:34:39 -0700

=======================================================
PWE3 Meeting Minutes -- IETF 53

Minutes Recorded by:

"Tom K. Johnson" <[email-masked]>
"Motty Anavi" <[email-masked]>

=======================================================
 o Danny goes over current status of work group 
   documents.

 o The expected deliverables are a common Edge to 
   Edge emulation maintenance protocol as well as 
   an applicability statement per draft.

=======================================================
Stewart Bryant -- Issues w/Protocol Layering Draft

Major topics included...

 o  Differing IP and MPLS approaches

 o Is a PW a wire or is it more complex?

 o Native Service Processing.

 o Principal of Minimum Intervention

Changes to draft include... 

 o The Position of the Timing and Sequencing layers 
   were swapped, since there is seems logical that 
   timing information may be dependent on sequencing 
   information.

 o The Tunnel layer has been renamed to be PW 
   identification layer, as that better describes its 
   purpose from a processing perspective.

 o Then he reviewed specific details on how the layers 
   described in the protocol layering draft would map 
   to IP implementations.  

 o Stewart mentioned that the IP ethos is to towards 
   generality and reuse of existing solutions while 
   other PSNs have different concepts.

   For example, a PW being carried over IP might make 
   the following choices in mapping layers:

     PSN = IP

     PW Identification = L2TP, GRE, IPSec, MPLS, etc.

     Tunnel Sequencing may be provided by a number of 
     different mechanisms.

   However, if you're using RTP, then of course you 
   should use RTP sequencing mechanism. 

 o Payload convergence as necessary for the specific 
   service.  And, in general the Payload should be sent 
   raw, unless there's a good reason.

Then Stewart led a similar discussion mapping services 
to MPLS

 o He noted that the PW over MPLS camp tends to value 
   efficiency more than the PW over IP camp.  And, that 
   this appeared to be a key difference between some of 
   the encapsulation proposals.

 o Stewart then demonstrated how Martini meets layering 
   model, but is simply more efficient from a header/
   payload standpoint.  (see slides for details)

Next discussion, where does the PW stop.  

 o Stewart asserted the architectural principal (which 
   was originally discussed back in Colorado), that the 
   PWs should simply emulate 'wires', and not attempt 
   to recreate service-specific processing functions 
   (such as those of an ATM switch or a SONET Multiplexer).  
   Those should be handled outside of the Pseudo Wire 
   using techniques defined by the relevant standards-bodies.

 o This non-PW processing is referred to as Native Service 
   Processing (NSP).  This is defined by the standards that 
   have ownership of that specific service (such as the ATM 
   Forum, ANSI, or the ITU-T).  The PW should simply be a 
   technique to carry the services through a PSN.  

 o Of course, the NSP function may be co-resident with the 
   PW Adaptation Function.

Next, Stewart discussed the "Principal of minimum intervention".  

 o He indicated that this is not dogma, but simply a way of 
   looking at the problem.  The guiding principal is that if 
   you fool around with the service payload as part of the 
   mapping, you're likely to break something.  If you carry 
   the payload transparently, you are less likely to have 
   problems.  And, it's simpler.  The primary issue that was 
   frequently sited against such an approach was efficiency.  
   Carrying ATM cell headers inside the PW when they will 
   likely be re-mapped at the other side of the network was 
   sited as a specific example of this inefficiency.

With that, several questions were posed to the working group 
to discuss on the list...

 1) How much manipulation of payload should we do?  
    (Stewart's thinking - unless there's a really 
    good reason, the payloads should be carried as 
    is.)  

 2) Is payload manipulation somehow dependent on PSN 
    Type?  For example the PSN=MPLS camp seems more 
    interested in efficiency.  

 o He noted that non-intervention has the advantage of 
   decoupling payload development from PW development, 
   but has disadvantage that it may be less efficient 
   on the wire.  

 o Next Stewart made a few suggestions about how/when RTP 
   should be applied to PW work.  Specifically, he said 
   that RTP is not necessary if an external clock is used 
   to provide timing for the service.  Otherwise, RTP 
   should be used for services that require timing support, 
   unless there was a very good reason.  

 o Stewart then discussed fragmentation.  Basically, try 
   to avoid it in the PW.  Try to get the CE to do it or 
   in the NSP.  However, if we need to support 
   fragmentation as part of the PW work, let's figure out 
   one way to do it for all PWs.  

Next, there was a discussion of different channel types.

 o For example, there appears to be a need for a very 
   reliable  control channel in many of the PWs.  Depending 
   on the service type, there may also be best-effort 
   channels and sequenced high-quality bearer channels, 
   and several other types in between.    

 o As a group, we need to define requirements.

Luca suggested that the list be used to comment on Stewart's 
presentation.  Then, some Q/A...

 1) Andy Malis noted that he had posted his issues and 
    wants to continue discussion on list.

 2) Khalid Ahmed noted that there is a sub-layering beneath 
    those shown in Stewarts doc.  Stewart said that much of 
    that could be addressed by the NSP.  Since we should 
    only be emulating a wire, we should be able to keep 
    things very simple.  Use existing specifications for 
    NSP behaviors rather than re-inventing them at the IETF.

 o Follow up - Suggestion that we should be more consistent 
   in our encapsulation schemes.  Stewart acknowledged that 
   we should strive for consistency, but there may be reasons 
   to diverge.  However, any differences should be clearly 
   justifiable.

=======================================================

Matthew Bocci -- Fischer vs Bayley for ATM PW

 o Matthew acknowledged that Fischer and Brayley had not 
   been able to reconcile their drafts into a single 
   document, so both parties had met with they had met 
   with ADs.  It was decided that Brayley and Fischer 
   would break down each encapsulation mode for both 
   drafts and evaluate applicability on a one-by-one 
   basis.  The goal being to reconstruct a single unified 
   draft for ATM PWs.  

 o Matthew stated that the purpose of Fischer is to 
   emulate VCC/VPC services on a cell by cell basis, 
   and an AAL5 frame mode (PDU and SDU) which he noted 
   is also simple to implement.  However, he said that 
   port mode had been removed.  

 o He noted that lots of issues with port mode had been 
   raised on mailing list.  And, that fault managemment 
   was identified as a major problem where there is no 
   way to isolate problems on a PW.  He noted that given 
   the original B-ISDN service model, port mode simply 
   doesn't fit.  He stated that ATM services are not 
   simply cell transport, it's VC and VP Connections, with 
   traffic contracts etc.  Without connections, there is 
   no way to recognize and enforce QoS requirements that 
   are essential to ATM.  And, there's no equivalent 
   service to an ATM port mode in the current networks.  
   So, it's not appropriate for PWE3.

 o VCC/VPC modes include single cell modes which are very 
   simple, but bandwidth inefficient.  Additional modes to 
   support concatenation of cells as well as AAL5 frame 
   encapsulation for improved efficiency.  

 o VPC mode saves label space with full management of ATM 
   services.

 o Q/A...  -- No questions

=======================================================

Jeremy Brayley - Brayley for ATM PW

 o He confirmed Matthew'ss statement that the ADs want 
   to see the two drafts converge.  And, that they are 
   trying to accomplish this by breaking down the two 
   drafts into the individual services.

 o Jeremy said that a key components of the debate was 
   based on whether or not VPI/VCI should be relayed 
   through the PW, and details of AAL5 mode.  And, of 
   course, port mode.  

 o Jeremy stated that service providers are looking to 
   migrate ATM services onto their IP backbones.  Then 
   he reviewed VCC cell relay, AAL5 VCC, AAL5 SDU, AAL5 
   PDU of his draft.  

 o Jeremy said that he didn't think that single cell 
   relay would be widely used due to ineffeciency.  He 
   also noted that there would be significant 
   differences between a PWE3 ATM connection and a 
   native ATM connection.  For example ATM cell headers 
   have single bit correction, whereas PWE3 ATM 
   connections will drop packets with bit-errors.  
   Also, since the PW must be transparent to the PSN, 
   there's no way to signal EFCI in the ATM cell headers 
   based on congestion in MPLS network.  
   
   Another issue he noted is that service emulations do 
   not provides "perfect emulations" as may the less 
   efficient cell relay.  So it's not exact emulation.  

 o However, Jeremy stated that existing ATM I.610/OAM 
   functions will need to work on the ATM PWs just as 
   they do today on ATM circuits.  

 o Next Jeremy discussed the merits of ATM Port Mode.  
   He acknowledged that port mode is most contentious.  
   But, Jeremy says that carriers want it.  It's a 
   simple way to interconnect ATM ports through a PSN.  
   There are problems with it, such as fault management, 
   but it seems like there should be workable solutions 
   for these.

 o Next, there was a discussion of the two modes of AAL5 
   carriage.  AAL5 SDU mode drops the padding, AAL5 
   trailer, and encapsulate the result.  The main 
   advantage of this approach is increased efficiency for 
   AAL5 traffic.  This is especially true for small 
   packets, where the padding needed to fill out to the 
   next cell can be almost as much as the payload.  This 
   is a well recognized problem for existing ATM networks.  
   Why carry it forward?

 o Jeremy says that main objection to AAL5 carriage is 
   lack of OAM support.  His view, if you need ATM OAM 
   support, don't use AAL5 mode, use cell mode.  

 o AAL5  mode.  Some carriers want to provide AAL5 service 
   that includes UU, FCS.  There's no need to recompute FCS.  
   However, Jeremy is lukewarm on this mode.

 o Khalid Ahmed Commented on the need to have applicability 
   statements.  AAL5 mode is not an ATM service, so it's 
   applicability is limited.  Same comment on port-mode.  
   Suggested that PWE might want to consider a generic port-
   mode that does not depend so much on service type.  

 o Jeremy said that providers are interested in ATM port 
   mode.  Jeremy has heard need from service providers to 
   generic port mode.  

 o Comment - there's no way to have a 'generic' port mode, 
   since you need to know what's inside the stream in order 
   to process.  For example, carriers want an ATM port mode 
   as a replacement for leased lines.  The ATM port mode 
   provides an opportunity for compression by not 
   transmitting idle cells.

=======================================================

Prayson Pate -- Status of the PWE3 Framework ID

 o He reviewed the history of the draft and noted that 
   the framework draft is now WG doc.

 o Lots of generalized clean up (see slides).  

 o Noted that it will need to be reworked a bit more to 
   be coherent with Bryant draft on protocol layering.

 o Q/A?  - no Questions

=======================================================

Ron Cohen -- Pate TDM ID

 o Main purpose of Pate's draft is to extend SONET/SDH 
   emulation to explicitly handle lower rate tributaries.  
   And, fractional STS-1 to conserve bandwidth on 
   unequipped VTs.  

 o Reviewed basic application of TDM aggregation over PSN.  

 o Noted changes since -02. (see slides)

 o He also noted that new revision is pending.  This 
   revision will include VC-4 support, similar to STS-1.  
   And includes some options for compression.  

 o He explained that this draft is relatively simple 
   extension to existing SONET/SDH emulation protocol by 
   Malis.  

 o Khalid Ahmed noted that the main application of this 
   draft is to be used as a distributed ADM. He then asked 
   why should service providers use a PW rather then an 
   ADM.

 o Ron responded by mentioning the commonality of this 
   application and the fact that the solution saves ports 
   in the central location.  

 o Chris Liljenstolpe - Comment to last questioner - 
   some service providers don't want to buy any more 
   SONET ADMs.  That's why they want to emulate SONET.

 o Stewart asks if this belongs in PWE3 since it emulates 
   a SONET ADM rather than a wire?  

 o Ron indicates that it is relatively easy to carry VT 
   formatted data, and this meets Stewart's minimum 
   intervention criterion.

 o Sasha remarked that the term end-to-end used in the 
   application slide does not correspond to end to end 
   terminology used in PWE3, i.e.  carrying information 
   from CE-to-CE.

 o Sim notes that this approach carries VT1.5, whereas other 
   schemes only carry the tributaries without the SONET VT 
   overhead.  He requested that the value of carrying the 
   VT1.5 overhead be explained in the applicability 
   statement.

=======================================================

Yaakov Stein -- TDMoIP ID

 o He explained that current revision is a major re-write 
   of original draft to bring it in line with current PWE3 
   terminology.  It provides more information about the 
   protocol layering.  It's been revised to support PW 
   types other than IP.  And he's added OAM for IPPM 
   measurements.   

 o He presented how TDMoIP format maps into Stewarts 
   nomenclature.  Major difference between this draft and 
   competing drafts is what payload is carried.  This draft 
   uses AAL1, AAL2, or HDLC to carry the different TDM 
   payloads.  

 o Yaakov asks rhetorically... Why use AAL1?  Isn't this a 
   violation of minimum intervention.  Yaakov attempts to 
   demonstrate that AAL1 is the simplest method to carry 
   TDM over packets.  Other approaches will fall apart on 
   packet loss, be less efficient.  And, he makes the point 
   that AAL1 is a debugged protocol that has been used for 
   years and is known to work.  AAL2 (another completely 
   designed and debugged protocol) can be used.

 o Yaakov discusses why TDM drafts have yet to converge, 
   the reason is that the motivation of the draft writers 
   is different. He suggests a possible approach to include 
   Raw Frame and SONET/SDH in addition to AAL1, AAL2, and 
   HDLC within his framework.  

 o Yaakov explains that one approach considers distribution 
   of SONET/SDH, another concentrates on raw TDM trunk 
   distribution while the third considers the lower end 
   structured and fractional TDM trunks.

 o To clarify, Yaakov proposed the following guidelines.

 o SONET/SDH could be used for high rate signals or for 
   distributing end-points that are already SONET.

 o For other rates:
 
   -  MUST use raw frames for unstructured.

   - MUST use AAL1 for structured static timeslot 
     and case.

   - MUST use AAL2 when dyanamic timeslot or bandwidth 
     allocations is required.

   - MAY use either AAL1 or raw for structured w/o CAS.

 o Danny asked that Yaakov float his proposal to the 
   mailing list.

=======================================================

Sasha Vainshtein -- CESoPSN ID

 o His proposal is Edge to Edge for TDM circuits.  It 
   supports NxDS0 service, unstructured DS1/E1, DS3/E3.

 o Sasha noted that his proposal uses RTP for timing 
   synchronization and sequencing.  And, that he had 
   worked with Steve Casner to iron out some issues 
   with the earlier revision of the draft.

 o Then, he reviewed several detailed slides of open issues 
   and changes.  (See slides for details).

 o Finally, Sasha raised the convergence issues with CESoPSN, 
   TDMoIP, and Pate's extensions to CEP.  He noted that after 
   a number of attempts, he had been unable to converge his 
   approach with Yaakov's TDMoIP.  He stated that he has not 
   yet tried to resolve issues with Pate's CEP extensions.  
   He noted that the big issue is resolution of payload 
   formats, which are quite different between the various 
   drafts.

 o Finally, Sasha raised some questions... 

 o Is a specific requirements statement needed for TDM?

 o What is RTP role in PWE3 w.r.t. TDM services?  

 o Q/A - 

 o Yaakov questions whether Sasha's proposal meets the minimum 
   intervention principal, due to how it handles CAS.  

 o Sasha disagrees.  

 o Donald O'Conner asked about how these different approaches 
   compare from a TDM performance perspective.  For example, 
   "How do they behave when exposed to packet jitter", "how 
   efficient are they", "how do they behave when packets are 
   dropped", etc.  The questioner noted that this line of 
   question should be critical in determining which of the 
   TDM proposals move forward. 

 o Sasha indicates that this analysis has not been completed.

 o Mr. O'Conner also notes that whatever the performance is 
   (from a TDM perspective) it will need to be verified on 
   live networks with live TDM traffic.  

 o Sasha notes this has not been performed or compared.

=======================================================

Mark Townsley -- Frame Relay over L2TP.

 o Tutorial style presentation - reference slides for 
   details.

 o Mark notes that his slides don't include anything above 
   the L2TPv3 header.  And that L2TPv3 can be carried of a 
   variety of packet-switched networks.

 o Mark shows that Frame Relay could be supported by L2TPv3 
   by adding a single AVP with two bits.  

 o Mark shows ladder diagram on how a frame relay circuit 
   would be provisioned using L2TP.  

 o Mark walks through various scenarios for service 
   establishment.  

 o Notes that shutting down on PVC doesn't require shutting 
   down the L2TP session.  

 o Then walks through session tear down example.  

 o Then compares his doc to competing PWE3 draft for Frame 
   Relay.  

 o He notes that the payload mappings are different, but 
   that's a general discussion.

 o However, his key point is that PVC control and maintenance 
   sections are not necessary, since it can be addressed by 
   L2TP with one AVP.

 o Khalid Ahmed asks what's the relationship between this 
   draft and the frame relay over MPLS draft.

   WMT notes that L2TP runs over IP and that other tunneling 
   protocols may be used over MPLS.

 o Andy Malis notes that there should be a distinction 
   between L2TPv2 and L2TPv3

   WMT agrees.

 o Question - What is the information that is sent in the 
   message to identify specific circuit at far end - 

   Mark - VPNID.  Configurable by software.

 o Question - why not use GRE?

   Mark answers that GRE is only encapsulation.  The 
   competing FR draft is mostly dealing with management.  
   Using L2TP, all the control plane issues are 
   addressed with existing protocols with minor 
   extensions.

 o Khalid Ahmed asks if there is work going on in Frame 
   Relay forum to carry Frame Relay over MPLS.  How does 
   this relate to that work.  

   Mark says that L2TP runs over IP and MPLS or anything 
   else.  So, it addresses all the necessary components of 
   the charter.

 o Khalid Ahmed asks if  FR over MPLS should use an 
   alternate protocol?

   Mark recommends that L2TP would work fine over MPLS as 
   well but other tunneling techniques may be considered.

 o Andy - notes that MPLS focused people would like to 
   stay with MPLS based protocol.  And, asks that L2TPv2 
   be noted separately from L2TPv3, since L2TPv2 is much 
   more widely deployed.

   Mark concurs that L2TPv2 is more widely deployed than v3.

=======================================================
David Zelig -- PWE3 MIBs.

(See presentation for diagrams)

 o David describes layers of MIB.  There is a service-specific 
   layer, a PWE3 Common Layer, and a PSN-specific layer.

 o Next he walks through mechanics of establishing a PW 
   using the MIB.  David indicates that the mapping of an 
   adaptation function to a tunnel can be thought of as a 
   kind of logical cross connect function.  And that this 
   is the way it is represented in the MIB.

 o Next he reviews the MPLS-specific PSN MIB and the Ethernet-
   Specific service MIB.

 o Next he shows relationship to interface stack table and 
   other standard MIBs.  

 o Next he reviews ATM-specific service MIB, and SONET-specific 
   service MIB (CEP).

 o David notes that the PWE3 MIBs are very stable now.  He asks 
   the WG for implementation input.  He states that he will be 
   adding support for notifications shortly.

 o Requests that this work be adopted as WG item.

=======================================================

Allison Mankin -- AD 

 o Notes that ADs ad WG chairs have coordinated on the 
   layering draft by Bryant.  

 o She says that we must remain focused on the fact that 
   PWs are not real wires.  

 o Applicability statements will note shortcomings.  

 o ADs and chairs will be meeting over coming weeks to 
   discuss differences between IP and MPLS PSNs.

 o Steve Casner noted that RTP header optional.  He asks 
   "is RTP/UDP/IP the right choice?"  If not, Steve would 
   recommend L2TP.  Allison confirms that RTP/UDP/IP is 
   appropriate for PWE3.  

 o Craig White - [lengthy comment that I was unable to 
   capture...] We should stay focused on carrying services 
   over IP rather than MPLS.  So, RTP/UDP/IP is the way 
   to go.  

   Craig clarified on mailing list:

   "Boy, I guess it's my own fault for the rambling 
    comment, but this doesn't match what I  meant  :)

    It was a 3 part comment, 

    First, I was making the observation that you don't 
    have to define your PW protocol using MPLS for the 
    PW to use MPLS. 

    Meaning IP packets are put into LSP tunnels currently, 
    so therefore, FR/L2TP/UDP may still end up in an MPLS 
    tunnel. Which was my answer to the question about do 
    you have to throw out UDP/L2TP/FR or UDP/RTP/SONET if 
    you also want/need to take advantage of MPLS features 
    such as traffic engineering, backup paths, etc.

    Secondly, I offered the observation that perhaps our 
    inability to move past some of our points of contention 
    (e.g.. portmode) is due to the way that the AD's choose 
    to define PWE3's work. 

    This was done in terms of service type (ATM, Ethernet, 
    TDM) rather than by encapsulation method (MPLS, L2TP, 
    RTP) or even by PW faithfulness (applicability 
    statements), or another dimension not yet defined. 

    Very early on, one of the requirements of what has 
    become PWE3 (esp.  from the point of view of an IP 
    service provider) was to use this technique to carry IP 
    traffic. By this I mean to recover the IP frame 
    "hidden" within the "native transport" protocol and 
    then to efficiently move that IP frame through the 
    network.

    My third observation was that other standards bodies 
    (ITU, ATMF, etc) perhaps saw a way to use an MPLS LSP 
    as a transport medium for their particular protocol and 
    to do this may require a lot of work that isn't 
    necessary to simply move IP packets."

 o Mark Townsley - Noted that there are two parts to L2TP, 
   encapsulation and control plane.  One can be used 
   without the other.  So, this should be kept in mind.  

 o Khalid Ahmed noted that there is much work going on 
   w.r.t. ATM over MPLS in other standards bodies.  How 
   will that work be reconciled.  

 o Danny - we will be focusing on applicability statements 
   and protocol layering.  So, monitor the mailing list for 
   the latest.  

 o Comment - we should hold an interim meeting to firm up 
   applicability statements, etc.  

 o Danny - That may happen but probably not per time 
   constraints w/Interim meeting, Yokohama coming up,
   etc.  Try to resolve without meeting.

 o Donald O'Conner notes that applicability statement 
   must note short-comings.