RE: Draft Minutes from PWE3 at IETF54

["Ron Cohen" <[e-mail]>]

Hi,

Please see comments inline

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Danny McPherson
> Sent: Wednesday, July 24, 2002 2:50 PM
> To: [e-mail]
> Subject: [PWE3] Draft Minutes from PWE3 at IETF54
> 
> 
> 
> Thanks to Jeremy Brayley for recording these!
> 
> Comments/corrections?
> 
> -danny
> 
> 
> **********************************************************************
> 
> July 14 PWE3 Working Group meeting  (9:00AM - 11:30AM) Yokohama IETF54
> -----------------------------------------------------------------
> -----------------------------------------------------------------
> Protocol layering document - Stewart Bryant  
> 
> Do we need GRE and IPSEC as tunnel types?
> 	3 people using GRE, nobody using IPSEC
> 	Need GRE text from those interested
> 
> Fragmentation section to be updated with 
> draft-malis-pwe3-fragmentation-00.txt
> 
> Payload Type section 3.3 could use some help, MPEG expert needed
> 
> Terminology - many docs have their own terminology section 
> Scott Bradner - proposes standalone terminology document
> 
> Work dependencies
> 	Need to sync up with PPVPN WG
> 
> -----------------------------------------------------------------
> PWE3 Fragmentation and Reassembly - Andy Malis 
> draft-malis-pwe3-fragmentation-00.txt
> 
> Fragmentation is required to send a frame larger than that 
> supported by the PSN Want a single set of 
> Fragmentation/Reassembly procedures rather than specifying 
> the procedures in each PWE3 service draft
> 
> Procedures adopted directly from RFC 1990 MLPPP
> 	Also used by FRF.12 and ATMF FAST
> Bit usage inverted from RFC1490
> Therefore not-fragmented packet looks the same as a packet 
> from a PE that doesn't implement fragmentation Signaling 
> additions - New VCFEC element parameter ID to signal the 
> ability to reassemble fragments
> 	Two new L2TP AVP pairs
> 
> Scott Bradner - questions why reassembly is optional.  He 
> believes it should be mandatory or not used at all Andy - PSN 
> MTUs are typically limited to 9K bytes Scott - The question 
> of whether to signal the ability to fragment and
>        whether to implement fragmentation are orthogonal
> 	If mandatory to implement, you can still use slowpath even if it
>        doesn't work well
> 
> --------------------------------------------------------------
> ---------
> Mark Townsley draft-townsley pwe3-l2tpv3-00.txt
> 
> Overview of l2tpv3
> 	Difference between LAC and LNS
> includes encapsulation (sessionid-cookies-flags-       
> 24bitsequencenumber)
> 
> PWE3 document organization discussion
> Mark proposes that PWE3 should generate the following 
> documents in a hierarchy
> **************************************************************
> pwe3 requirements     --------> pwe3 Framework and
>                                 Protocol layering
> 
> Pseudo wire documents --------> pwe3 mibs
> (fr, eth, hdlc)				(fr,etc,hdlc)
> 
> PW over MPLS			  PW over L2TP/IP
> (fr, eth, hdlc)				(fr, eth, hdlc)
> **************************************************************
> 	
> ????- how about a single document for MPLS and a single doc for L2TP?
> 	then PW specific documents can refer to a field defined in these
>         docs
> 	like "these bits go into the flags field defined in the PW over
>         L2TP doc"
> Luca - ordering should be reversed
> Scott- should PW over MPLS and L2TP have any fr, eth, hdlc 
> specific info at all?
> 
> --------------------------------------------------------------
> ---------
> draft-reigel-pwe3-tdm-requirements-00.txt
> open issues
> 	more terminology necessary for TDM emulation
> 	need specification of CAS and CCS
>               Channel associated signaling and common channel 
> signaling
> 	need synchronization reference model
> 	should requirements for SONET/SDH emulation be added?
> 
> Danny- This should definitely become a WG document
>        Should it be folded into the current requirements document?
> Scott- fundamental question is whether we should try to emulate
>        technology exactly or point out what is different
>        Emulation is not necessarily useless even if it 
> doesn't meet every
>        application's requirements
> Yaakov - want to fold these requirements into TDM documents 
> since some of
>          these requirements are very specific to a particular TDM
>          application
> 
> --------------------------------------------------------------
> --------------
> --------------------------------
> TDMoIP Real world issues - Yaakov Stein  
> 
> RAD - over 9000 TDMoIP ports deployed
> Market wants average of 4 E1/T1 ports per edge device
> Less than 1% of ports were E3/T3
> The point is that T1 level emulation is a more appropriate 
> problem to solve
> 
> School districts began using voice over IP, but they didn't 
> like voice quality and delay RAD replaced VoIP with TDMoIP
> 
> >90% of access network is CAS (PBX interconnect)
> 
> Kireeti - Makes the comment that Yaakov's presentation is too much
>           marketing for his taste
> Scott - Asks Yaakov to concentrate on facts
> 
> AAL1 - requires high reliability
> AAL2 - useful for toll bypass, people don't expect 
> high-reliability -ex. point of sale applications
> 
> Cellular telephony 
> Requires 50ppb clock accuracy  - will RTP really work here?
> 
> Scott - Maybe 50ppb should not be a design group goal, maybe 
> PSN should
>         not be used for some applications.  It is not the PWE3 group's
>         goal to define procedures to support every application.
> 	
> Yaakov 50ppb can be done, but requires a lower layer 
> mechanism different from RTP
> 
> Ray Jangar?  (PMC Sierra) - TDM over IP is a real requirement 
> - seeing requirement heavily in Asia
> 
> --------------------------------------------------------------
> --------------
> --------------------------------
> CESoPSN update  - Sasha Vainshtein draft-vainshtein-cesopsn-03.txt  
> 
> Control word aligned as much as possible with 
> draft-malis-pwe3-sonet-03
> 	Structure pointer is always 0
> 
> Will emulated CE to CE service experience prolonged outage if 
> an occasional CESoPSN packet is lost?
> 	No for both structured and unstructured modes, but for 
> different reasons...
> 
> Convergence issues 
> 	Common applicability statement and control word with draft-pate
> (CEP)
> 	CESoPSN vs TDMoIP (draft-anavi)
> 
> --------------------------------------------------------------
> ---------
> Extending SONET/SDH CEP for low rate signals -  Ron Cohen 
> draft-pate-pwe3-sonet-vt-00.txt 
> 
> This draft extends draft-malis to SONET VT1.5/2/3/6 and SDH VC-11/12/2
> 	but with no extension to its applicability statement
> It adds bandwidth saving modes
> 
> ??? - Why add vt3, vt6 since they are not used in the real 
> world? Ron - agrees, but vt3 and vt6 come for free
> 

TDM Common Applicability  Statement - Ron Cohen
 http://www.ietf.org/internet-drafts/draft-cohen-pwe3-tdmsonetapp-00.txt

common to:
draft-malis-pwe3-sonet-03.txt
draft-pate-pwe3-sonet-vt-00.txt
draft-vainshtein-cesopsn-03.txt

> Applicability 
> 	fidelity of emulated TDM services
> 	fault isolation and performance monitoring
> 	PSN considerations - path MTU, bandwidth saving modes
> 
> P2P PDH emulation
> MP2MP SONET/SDH emulation
> 	draft-malis-pwe3-sonet-01.txt does STS-1 and above
> 	draft-pate extends to VT level
> MP2P PDH to SONET emulation
> 
> common applicability statement
> 
> --------------------------------------------------------------
> ---------
> Andy Malis   - Frame Relay draft 
> 	no slides - We have seen the presentation too many times already
> 	Have reached agreement on encapsulation
> 	Must decide how to organize documents (1 doc, 2 docs ?)
> 
> --------------------------------------------------------------
> ---------
> ITU developments in ATM encapsulations  SG13 -Ghassem Koleyni
> 	ATM-MPLS Network Interworking
> ITU has agreed on a compromise that allows both "Martini" 
> style encapsulations and ATMf style encapsulations
> 
> Two cell modes
> 	one to one mode (based on ATMF cell mode - includes VCI present
>                          bit, PTI,CLP)
> 	N to one mode (original Martini encap - includes 
> VPI/VCI,PTI,CLP) Frame modes
> 	AAL5 PDU
> 	AAL5 SDU
> 
> Ghassem shows the encapsulation for each mode
> 
> ITU has produced two documents
>        cell modes defined in Y.atmplsC
>        frame modes defined in Y.atmplsF
> 
> Stewart - why are the control words different?
> 	Please repeat part about security
> Ghassem - OAM security cell needs to be sent right away, 
> can't re-order
>         these admin cells with user cells
> Danny - wants to see compromise encapsulations posted to 
> mailing list Ghassem - people involved should get together 
> this week to combine drafts Scott - it has been a problem in 
> the past when multiple standards bodies
>         come up with solutions to the same problem - random 
> movement of
>         bits is not a good idea
> 
> --------------------------------------------------------------
> ---------
> Discussion of Martini ATM and Ethernet drafts - Luca Martini 
> draft-martini-atm-encap-mpls-01.txt
> changes since 00
> 	merged draft-martini-atm-encap-mpls-00 and 
>                draft-brayley-pwe3-atm-service-01
> 	added appendix about defect handling
> 	cell port mode moved to appendix
> 	removed AAL5 PDU mode, will put it back in based on 
> draft-fischer
> 	added applicability statements
> 
> Will merge content with draft-fischer-pwe3-atm-service-02
> 
> draft-martini-ethernet-encap-mpls-01.txt
> 	merged draft-so-pwe3-ethernet
> 
> ??? - Why two modes?  One strips vlan from packet before 
> sending on the tunnel and one keeps VLAN tag Luca - Most 
> vendors use VLAN tag mode since it is easy to implement on
>        routers.
>        The goal is to produce encapsulations that most 
> vendors are able
>        to implement 
> Stewart and Mark Townsley - use principle of minimal intervention and
>        keep VLAN tag, don't strip the VLAN tag
> Scott - at minimum we should have one required mode
> Ragu - why is this different from FR encapsulation?
> Kireeti - Ethernet switches don't switch VLAN tags but FR switches do
>         switch DLCIs
> 
> Discussion of draft-martini-l2circuit-trans-mpls-09.txt
> 
> Add requirement for VLAN translation at egress (currently an 
> option) Move IANA considerations to separate document
> 
> Scott - Split references for normative and non-normative 
> references in documents
> 
> Other items
> 	need to provide inter-domain solution
> 	IANA guideline document
> 
> Kireeti - Should this work be done in PPVPN or PWE3?  
> (exchanging VC labels) Danny - Endpoint discovery is PPVPN, 
> signaling setup and maintenance is PWE3 Kireeti - Why is VPLS 
> in PPVPN and not in PWE3? Scott - We have been assuming that 
> all circuit establishment is in PWE3 Scott - What is 
> different at byte level between intra- and inter-domain PW 
> emulation? Luca - byte level is not different but maintenance 
> is different
>        one domain should not be able to establish circuits across 
>        another domain
> 
> --------------------------------------------------------------
> ---------
> Danny - please reword documents to align with protocol layering
>         documents - most are not
> Danny - Security considerations are currently very weak - must be
>         addressed or docs will not be progressed
> 
> Scott - Hackers are really interested in seeing wide-area 
> layer 2 networks Kireeti - It is sad that we have converged 
> on a single encapsulation
>         because we could make the hackers guess at which mode is being
>         used!
> Scott - This is called security through obscurity...
> 
> ********
> Meeting adjourned at 11:15.
> 
> 
> 
> _______________________________________________
> pwe3 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/pwe3
>