Subject: Re: Draft Minutes from PWE3 at IETF54

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 24 Sep 2002 16:49:28 -0400

Danny,

There were a lot of comments on the minutes.  Was a final version ever issued?

Thanks,
Andy

------

At 7/24/2002 06:50 AM -0600, Danny McPherson wrote:

>Thanks to Jeremy Brayley for recording these!
>
>Comments/corrections?
>
>-danny
>
>
>**********************************************************************
>
>July 14 PWE3 Working Group meeting  (9:00AM - 11:30AM) Yokohama IETF54
>-----------------------------------------------------------------

---

From: Eric Rosen <[email-masked]>
Date: Wed, 24 Jul 2002 10:55:06 -0400

>From the minutes: 

> 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

It seems like we've been trying to figure out for years whether signaling is
in the province  of PWE3 or PPVPN or  (in the case of MPLS)  MPLS, and we've
never really  gotten a  straight answer.  However,  most of  the significant
discussion of signaling has occurred in PPVPN, and there are WG documents in
PPVPN that  discuss signaling.  So I for  one am surprised to  find out that
anyone  has been  secretly assuming  that  all circuit  establishment is  in
PWE3. 

I  would like to  see a  jointly signed  statement in  writing from  ALL the
involved WG chairs and ADs stating the division of work clearly. 

Frankly, I think it makes more  sense to have the signaling in PWE3, because
that enforces a clear separating of circuit setup/maintenance signaling from
the VPN provisioning issues.  

As "martini  signaling" and its  off-shoots require LDP extensions,  I would
also like some clarification as to the  way in which the MPLS WG needs to be
involved.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 24 Jul 2002 16:45:12 -0400

At 06:50 AM 7/24/2002 -0600, Danny McPherson wrote:

>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)
>**************************************************************
>

         Just to be precise, the PWE MIB documents
fit into the following picture (as described in the Framework):

pwe3 requirements     --------> pwe3 Framework and
                                 Protocol layering

Pseudo wire documents --------> pwe3 mibs
(fr, eth, hdlc)                         (fr,etc,hdlc)
                                                               /
                PW-VC MIB  (for general PW VCs)
                     /                                              \
PW over MPLS                      PW over L2TP/IP
(fr, eth, hdlc)                         (fr, eth, hdlc)
PW over MPLS MIB                             PW over l2TPv3 MIB (TBD)

         --Tom

>????- 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
>
>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
>
>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
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/pwe3

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 24 Jul 2002 20:43:21 -0400

Comments inline ....

>Thanks to Jeremy Brayley for recording these!

I don't think this quite reflected the exchange, although Scott was quoted 
accurately.

My primary point in the discussion was that I personally had no problem 
with Scott's suggestion that reassembly be made mandatory, even though the 
specified signaling is pretty simple.

Other speakers disagreed and felt that the ability reassembly shouldn't be 
required, and that the signaling should be retained.  As I recall, the 
conclusion was to take the discussion to the list.

I said that the discussion at this point is strictly editorial on document 
organization.

Thanks,
Andy